Coding Standards
General
- Design in an object-oriented style wherever appropriate.
- Make it as simple and flexible as possible.
- Comply with Object Oriented Design Standard of CoreLinux?++ Project for the Object-Oriented design.
- Use C++, Python and shell script for programming.
- Make it as portable as possible.
(see TargetPlatforms?)
- Do not reinvent wheels.
- Always look for existing software / software components BEFORE writing original code.
- Pay attention to the license when considering to incorporate third-party software.
- Look for a verb for a method name from the following list first. Need to devise a new verb is not often.
- get/set (accessor, mutator)
- create (create new object)
- add/remove (add/remove an object from a list)
- is (boolean predicate)
- clear
Packaging
- Comply with LSB: Linux Standard Base for packaging on linux
- Comply with FHS: Filesystem Hierarchy Standard for POSIX systems
- LSB requires FHS
C++
- Comply with C++ Coding Standard of CoreLinux?++ Project.
- However, do not use libcorelinux (rationale: not portable)
- In type declarations (such as template parameters), use typename if both primitive types and classes are intended, or use class if only classes are expected.
example: template< class CLASS, typename TYPE_OR_CLASS > - Use the default setting of the c++-mode of the emacs editor (or equivalent) for indentation!!
- Use of exception is recommended.
- Try to place try{} block only where performance is not critical.
- Do not use exception specification.
- Write comments in Doxygen-style
python
- Use a subset of the C++ Coding Standard. (e.g. naming convention)
- (IMPORTANT!) Use the default setting of python-mode of the emacs editor for indentation.
- --> PythonCodingStyle?
shell scripts
- Use of shell script should be limited to very 'core' commands, because UNIX shell is not available on all platforms (especially Windows).
For this reason, if a shell script is used, an equivalent .bat script must be provided for Windows. Better if a Python script is written. Because E-Cell 3 itself uses Python, the language interpreter can be assumed to be always available.
- Use default setting of the sh-mode of the emacs editor for indentation.
- Use /bin/sh
UML
- Use XMI to exchange UML
- Use of Argo/UML is recommended. (Poseidon is now not compatible with Argo/UML.)
XML
- Use XML schema, rather than DTD, wherever possible.
Documentation
- Use DocBook? version 4 for technical documents (such as reference manuals and tutorials).
