Typedefs | |
| using | softtabstop = 2 To set the mod-N indentation used when you hit the tab key in vim(what Emacs calls c-basic-indent), do this:set shiftwidth=2 To cause the TAB file-character to be displayed as mod-N in vi and vim(what Emacs calls tab-width), do this:set tabstop=4 To cause TAB characters to not be used in the file for compression, and for only spaces to be used(what emacs calls indent-tabs-mode), do this:set expandtab 12.1) I work on several projects and each uses a different indent format. What do I do? Taken from an email from Eric Estabrooks< estabroo @talkware.net >, which is based on info found in the linux kernel. add to your .emacs |
Functions | |
| set linux kernel mode for anything in usr src linux *setq auto mode | alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode) auto-mode-alist)) 13) Its much easier to spot the block comments if they all start with * |
| if< space > (expression) | |
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate or even if the bug is still there Please also state what version of crossfire the diff is for I will assume any patches mailed directly to me are to be included If posting a patch on the mailing | list (either source or ftp location) |
| linux kernel c | mode (defun linux-c-mode() "C mode with adjusted defaults for use with the Linux kernel."(interactive)(c-mode)(c-set-style "K&R")(setq c-basic-offset 8)) |
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a | patch (feature X is nice, but Y doesn 't work). 2) Please state in the message included with the patch what it fixes/changes. Too often |
Variables | |
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source | code |
| set linux kernel mode for anything in usr src linux *setq auto mode and these comments tend to be worth noticing As discussed on | irc |
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate | it |
| int | my_long_var_name |
| I ve redone this file to hopefully make it a little easier to read through and quickly get some idea what to do There are sections section is current programming style hints for developers to make things easier Section is programming guide for new addition Section is notes for making patches Section currently used conventions hints for new code ob is for | object |
| No space after the left no space before the right paren Comma right after the formal space right after the comma Local variable names Just a rules of thumb These are | ok |
| No space after the left no space before the right paren Comma right after the formal | param |
| The preferred style of formal | param2 |
| The preferred style of formal | param3 |
| The preferred style of formal | parameters |
| No space after the left | paren |
| Please do NOT use caps expect for enums and defines Section sending in | patches |
| statement | |
| set linux kernel mode for anything in usr src linux *setq auto mode and these comments tend to be worth noticing As discussed on the preferred style for expressions is like | this |
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate or even if the bug is still there Please also state what version of crossfire the diff is for I will assume any patches mailed directly to me are to be included If posting a patch on the mailing please explicity state whether or not you want that patch incorporated into the master source Many | times |
| Please do NOT use caps expect for | typedefs |
| I ve redone this file to hopefully make it a little easier to read through and quickly get some idea what to do There are sections section is current programming style hints for developers to make things easier Section is programming guide for new addition Section is notes for making patches Section currently used conventions hints for new code | writers |
Typedef Documentation
◆ softtabstop
| using softtabstop = 2 To set the mod-N indentation used when you hit the tab key in vim (what Emacs calls c-basic-indent), do this: set shiftwidth=2 To cause the TAB file-character to be displayed as mod-N in vi and vim (what Emacs calls tab-width), do this: set tabstop=4 To cause TAB characters to not be used in the file for compression, and for only spaces to be used (what emacs calls indent-tabs-mode), do this: set expandtab 12.1) I work on several projects and each uses a different indent format. What do I do? Taken from an email from Eric Estabrooks <estabroo@talkware.net>, which is based on info found in the linux kernel. add to your .emacs |
Definition at line 161 of file style-guide.txt.
Function Documentation
◆ alist()
| set linux kernel mode for anything in usr src linux* setq auto mode alist | ( | cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode) auto-mode- | alist | ) |
◆ if< space >()
◆ list()
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate or even if the bug is still there Please also state what version of crossfire the diff is for I will assume any patches mailed directly to me are to be included If posting a patch on the mailing list | ( | either source or ftp | location | ) |
◆ mode()
| linux kernel c mode | ( | defun linux-c- | mode) "C mode with adjusted defaults for use with the Linux kernel."(interactive)(c-mode)(c-set-style "K&R")(setq c-basic-offset 8 | ) |
Referenced by AssetOriginAndCreationDialog::AssetOriginAndCreationDialog(), cf_timer_create(), cfapi_timer_create(), cftimer_create(), cftimer_find_free_id(), cftimer_process_timers(), check_path(), command_party_rejoin(), CREPrePostList::CREPrePostList(), CREPrePostPanel::CREPrePostPanel(), CRESubItemQuest::CRESubItemQuest(), Crossfire_Object_CreateTimer(), find_in_layout(), get_pickup_mode_index(), init_attackmess(), main(), mtar_open(), object_matches_pickup_mode(), and PrePostWidget::PrePostWidget().
Here is the caller graph for this function:
◆ patch()
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a patch | ( | feature X is | nice, |
| but Y doesn 't | work | ||
| ) |
Variable Documentation
◆ code
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source code |
Definition at line 237 of file style-guide.txt.
◆ irc
| set linux kernel mode for anything in usr src linux* setq auto mode and these comments tend to be worth noticing As discussed on irc |
Definition at line 190 of file style-guide.txt.
◆ it
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate it |
Definition at line 238 of file style-guide.txt.
◆ my_long_var_name
| int my_long_var_name |
Definition at line 223 of file style-guide.txt.
◆ object
| I ve redone this file to hopefully make it a little easier to read through and quickly get some idea what to do There are sections section is current programming style hints for developers to make things easier Section is programming guide for new addition Section is notes for making patches Section currently used conventions hints for new code ob is for object |
Definition at line 11 of file style-guide.txt.
Referenced by nlohmann::detail::hash(), locate_recipe_artifact(), malloc_info(), nlohmann::detail::json_sax_dom_parser< BasicJsonType >::start_object(), and nlohmann::detail::json_sax_dom_callback_parser< BasicJsonType >::start_object().
◆ ok
| No space after the left no space before the right paren Comma right after the formal space right after the comma Local variable names Just a rules of thumb These are ok |
Definition at line 222 of file style-guide.txt.
Referenced by CRESubItemConnection::editChanged(), is_defined_recipe(), and CRESubItemConnection::setData().
◆ param
Definition at line 215 of file style-guide.txt.
Referenced by add_template_to_render(), check_tables_callback(), command_purge_quest(), command_purge_quest_definitions(), do_test(), generate_page_and_link(), and set_up_cmd().
◆ param2
| The preferred style of formal param2 |
Definition at line 209 of file style-guide.txt.
◆ param3
| The preferred style of formal param3 |
Initial value:
Definition at line 209 of file style-guide.txt.
◆ parameters
| The preferred style of formal parameters |
Definition at line 209 of file style-guide.txt.
Referenced by initapply(), initapplyobject(), initcamera(), initdropobject(), initfire(), initghosted(), initmessage(), initmovement(), initmoveto(), initnotice(), initpickup(), initpickupobject(), initsay(), initstop(), initteleport(), inittrigger(), initturn(), initvisible(), initwizard(), parse_animation_block(), runapply(), runapplyobject(), runcamera(), rundropobject(), runfire(), runghosted(), runmessage(), runmovement(), runmoveto(), runnotice(), runpickup(), runpickupobject(), runsay(), runstop(), runteleport(), runtrigger(), runturn(), runvisible(), and runwizard().
◆ paren
| No space after the left paren |
Definition at line 214 of file style-guide.txt.
◆ patches
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate or even if the bug is still there Please also state what version of crossfire the diff is for I will assume any patches mailed directly to me are to be included If posting a patch on the mailing please explicity state whether or not you want that patch incorporated into the master source Many a patch may be made available on an expiremental basis which is not ready for widespread distribution When making patches |
Definition at line 231 of file style-guide.txt.
◆ statement
| statement |
Definition at line 194 of file style-guide.txt.
◆ this
Definition at line 193 of file style-guide.txt.
◆ times
| Please do NOT use caps expect for enums and defines Section sending in and not make mega patches A diff that changes things is first more difficult for me to look over and understand as unrelated changes might be going on It is also harder for me to reject part of a I get patches which is just a bunch of source and I have no idea if I want to incorporate or even if the bug is still there Please also state what version of crossfire the diff is for I will assume any patches mailed directly to me are to be included If posting a patch on the mailing please explicity state whether or not you want that patch incorporated into the master source Many times |
Definition at line 244 of file style-guide.txt.
◆ typedefs
| Please do NOT use caps expect for typedefs |
Definition at line 225 of file style-guide.txt.
◆ writers
| I ve redone this file to hopefully make it a little easier to read through and quickly get some idea what to do There are sections section is current programming style hints for developers to make things easier Section is programming guide for new addition Section is notes for making patches Section currently used conventions hints for new code writers |
Definition at line 10 of file style-guide.txt.
