DROS Coding Standards

Maintained by: David Austin

If you want your code to be included in the DROS distribution, then I suggest the following rules:

All lines should be less than 80 characters wide.
Avoid the use of modern C++ constructs:
1. Avoid the use of the C++ constructs template or namespace. These are not standardised yet.
2. Do not use the C++ constructs namespace, template, string, or bool in any code that may be needed under a real-time OS. This is most important for the basic building blocks and for the proxies because they may be used anywhere.
3. Avoid the use of the C++ "Standard" Template Library (STL). It is not standardised yet (try porting something to gcc 3.2).
Documentation should be included in/with the code. Firstly, the code should be fairly self-explanatory with comments at any tricky part. The overall structure/algorithm should be documented, either by reference to a paper or in html in the doc directory. Note that it is most important to document the high-level stuff so that others know and understand how your stuff fits in - the low-level stuff should be reasonably documented by the code.
Please spend some effort to make your code as bullet-proof as possible. It's fine to take shortcuts while you're developing it and doing research but if you want to release it, I think that it needs to be more robust. Implement error checking everywhere, remove any assumptions that you can and document the remaining assumptions.
Avoid the use of C++ pure virtual functions. The compiler prevents you from calling them in most cases but there is at least one case where they can be called. In the destructor method, it is possible to call pure virtual member functions by mistake (because of the ordering of destruction of inherited objects) and then your program terminates immediately with the (extrordinarily helpful) message pure virtual function called. It doesn't tell you anything! So, instead of using pure virtual functions, define the function to print out some helpful message and then exit. Or even better, send the currently running process a SIGSEGV signal in the hope of getting a core dump and backtrace so that you can really work out why the pure virtual function was called.