Coding Standards

General

  • Design in an object-oriented style wherever appropriate.
  • Make it as simple and flexible as possible.
  • 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).