580
edits
C++ Tips: Difference between revisions
Jump to navigation
Jump to search
→Formatting and Style
m (→Standards) |
|||
| Line 14: | Line 14: | ||
* Use exceptions. Exception support is not well developed, but they provide a clean way to handle genuinely unusual situations without (easily ignorable) bool or integer return codes. The main loop catches exceptions, so use the SimGear exception classes, provide good location and message strings when you throw, and all should be well. Using exceptions can greatly simplify code, by removing continual failure / error checks in the main code. | * Use exceptions. Exception support is not well developed, but they provide a clean way to handle genuinely unusual situations without (easily ignorable) bool or integer return codes. The main loop catches exceptions, so use the SimGear exception classes, provide good location and message strings when you throw, and all should be well. Using exceptions can greatly simplify code, by removing continual failure / error checks in the main code. | ||
* Ensure headers are independent and minimal (see the discussion of forward declarations further down). This means each header should include everything it needs to parse, and no more. Header should feature the following (in order): | |||
** an <tt>#ifndef</tt> guard | |||
** a one line comment stating the purpose of the file (or a full Doyxgen @file block if you prefer) | |||
** The GPL license boiler plate | |||
** The CVS revision tag | |||
** 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 | |||
** ''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. | |||
* Source files should have the following structure: | |||
** A one line comment (or Doxygen @file section) describing the purpose of a file. If you're copying an existing file, please remember to update the comment | |||
** The GPL license boilerplate | |||
** The CVS revision tag | |||
** The <tt>#ifdef HAVE_CONFIG_H</tt> boilerplate include | |||
** An include of the header file corresponding to the source file. This provides an excellent test that the header file is independent - since it's the first thing included, that guarantees it correctly pulls in any other headers it may depend upon. | |||
** Any required includes, again grouped by kind as discussed for header files - generally 'simplest first' | |||
** Any namespace, forward declarations or <tt>using</tt> declarations. It's important that these occur after including all headers, to ensure the environment see by the headers is not polluted, which may conceal or cause problems. | |||
== Standards == | == Standards == | ||