![]() |
Coding guidelines |
Introduction Screenshots Mailing Lists and IRC Alternative Browsers Special Thanks
FAQ
Download binaries Platforms Compiling Mnemonic Other useful software
Core Message modules Library modules Object modules Coding Guidelines Browse Source Using CVS
Website questions to: |
There are quite a few C++ experts on the project. If you're not sure about how to code something, or if you don't understand the guidelines here, please post a message to dev@mnemonic.org. The C++ FAQ is also a very helpful guide.
Avoid uppercase characters. Use a '.cc' extension for C++ code and a '.h' or '.hh' extension for C++ headers.
Avoid capitals in variables and member functions; use underscores to separate words. All private variables and member functions should have an underscore postfixed (ie. 'somefunction_(void)' and 'int somevar_;').
Our indentation style is defined by the 'emacs-indentation-style' file in the core subdirectory, which you can put in your '.emacs' file. To trigger it automatically, all .h/.hh/.cc files should start with the line // -*- mode: C++; c-file-style: "mnemonic"; -*-This enables you to still have a different style for other C++ projects. The logic defined in the emacs file amounts to the following: class foobar { public: member1(); member2(); private: member3_(); int var_; }; for(foobar) { dosomething(); domore(); } if(something) { dothis(); } else { dothat(); } int someclass::somemember() { herewego(); }All indentation is done using TABs which (in those emacs settings) are 3 spaces wide.
We use STL containers everywhere. There are very few good reasons for sticking to standard C style 'malloc/strdup/free' and friends. To be precise, use them only when interfacing to a C library (see eg. the interface to the jpg library). Information about STL containers can be found at SGI's STL pages. Note that 'malloc' and friends do not call constructors, and their memory heap routines are not compatible with the ones of 'new' and co. Many constructors accept 'const char *' pointers to names, urls, etc. Always copy this information into private storage, since you'll never know how long the pointer is going to be valid. Use C++ strings for this; see below. Our convention is that passing a pointer (to allocated memory) to another object does not mean passing ownership. The object that allocated the memory remains responsible for freeing, unless explictly specified in the class definition. In all cases, try to avoid these situations by copying data, as described above.
Use the standard C++ 'string's for all string manipulations, together with the 'strstream' streams. In order to avoid namespace clashes, always do '#include <string>' as the first thing in your file. Do not put it below other includes, and do not use the 'string.h' file.
Think carefully about the constness of your objects. Put these keywords in from the very beginning. It's absolutely crucial if you don't want to run into trouble when using STL. See the section on const correctness in the C++ FAQ for more motivation.
Try to make your header files as clean as possible; large blocks of text make them unreadable. If you need comments, try to make them one line long. Put extra information in the '.cc' file. Write a bit of normal English in a html file and store it in the 'docs' directory if you want to be really user-friendly.
An excellent reference guide to the STL is provided by SGI's STL pages. |