580
edits
C++ Tips: Difference between revisions
Jump to navigation
Jump to search
→Formatting and Style
| Line 26: | Line 26: | ||
** any required includes, ideally grouped by kind - for example standard C library, then standard C++ library, then SimGear, then other FlightGear headers | ** any required includes, ideally grouped by kind - for example standard C library, then standard C++ library, then SimGear, then other FlightGear headers | ||
** any forward declarations or namespaces required | ** any forward declarations or namespaces required | ||
** ''ideally'', exactly one class (which should match the name of the file). This rule is frequently broken in the existing code, and there are reasons not to obey it, but in general, simpler, standalone headers which define one class are much easier for developers, packagers, code indexers and compilers to deal with. | ** ''ideally'', exactly one class (which should match the name of the file). This rule is frequently broken in the existing code, and there are reasons not to obey it, but in general, simpler, standalone headers which define one class are much easier for developers, packagers, code indexers and compilers to deal with. | ||
Headers should ''not'' feature a <tt>#ifdef HAVE_CONFIG_H</tt> block if at all possible (compiler portability sometimes defeats this). Source files ''should'' be including <tt>config.h</tt> as their first action, before including any real headers. Again, currently there are files in the codebase that do not follow this pattern. | Headers should ''not'' feature a <tt>#ifdef HAVE_CONFIG_H</tt> block if at all possible (compiler portability sometimes defeats this). Source files ''should'' be including <tt>config.h</tt> as their first action, before including any real headers. Again, currently there are files in the codebase that do not follow this pattern. | ||
| Line 42: | Line 42: | ||
* Break long functions and methods. Ideally, functions should fit on one screen - scrolling back up a function to check scope or variable naming harms readability. Sometimes longer methods do make sense, but the longer the method gets, the better your local variable naming needs to be. | * Break long functions and methods. Ideally, functions should fit on one screen - scrolling back up a function to check scope or variable naming harms readability. Sometimes longer methods do make sense, but the longer the method gets, the better your local variable naming needs to be. | ||
* Typedef instantations of STL containers. This greatly aids readability, but also makes changing the definition much simpler - especially when using iterators, as is very common with the STL containers. It's much better to refer to <tt>IdNavaidMap::iterator</tt> than <tt>std::map<std::string, Navaid*>::iterator</tt> at each point you refer to an iterator type. | |||
== Standards == | == Standards == | ||