---

Coding standards

As a general rule, you should always try to continue computations, even if there is some kind of error. When the program stops, it is often very hard for a user to pinpoint what part of the input causes an error. Finding the culprit is much easier if there is some viewable output.

So functions and methods do not return errorcodes, they never crash, but report a programming_error and try to carry on.

Languages

C++ and Python are preferred. Python code should use PEP 8.

Filenames

Definitions of classes that are only accessed via pointers (*) or references (&) shall not be included as include files.

   filenames

        ".hh"   Include files
             ".cc"      Implementation files
             ".icc"     Inline definition files
             ".tcc"     non inline Template defs

   in emacs:

             (setq auto-mode-alist
                   (append '(("\\.make$" . makefile-mode)
                        ("\\.cc$" . c++-mode)
                        ("\\.icc$" . c++-mode)
                        ("\\.tcc$" . c++-mode)
                        ("\\.hh$" . c++-mode)
                        ("\\.pod$" . text-mode)
                        )
                      auto-mode-alist))

The class Class_name is coded in ‘class-name.*’

Indentation

Standard GNU coding style is used. In emacs:

             (add-hook 'c++-mode-hook
                  '(lambda() (c-set-style "gnu")
                     ))

If you like using font-lock, you can also add this to your ‘.emacs’:

             (setq font-lock-maximum-decoration t)
             (setq c++-font-lock-keywords-3
                   (append
                    c++-font-lock-keywords-3
                    '(("\\b\\(a-zA-Z_?+_\\)\\b" 1 font-lock-variable-name-face)                    ("\\b\\(A-Z?+a-z_?+\\)\\b" 1 font-lock-type-face))
                    ))

Classes and Types

             This_is_a_class

Members

Member variable names end with an underscore:

     Type Class::member_

Macros

Macro names should be written in uppercase completely.

Broken code

Do not write broken code. This includes hardwired dependencies, hardwired constants, slow algorithms and obvious limitations. If you can not avoid it, mark the place clearly, and add a comment explaining shortcomings of the code.

We reject broken-in-advance on principle.

Naming

Messages

Messages need to follow Localization guidelines

---