----
[[PageOutline(1-6,,inline)]]
----

= Coding Style = #style

== How MoleCuilder code should look like == #style-file

Below you find a brief but hopefully complete list on how the code of espack should look like:

   * identate by two spaces, never tabs
   * Code Style from Eclipse, see [attachment:ESPACK_codestyle.xml]:
{{{
/*
 * A sample source file for the code formatter preview
 */
#include <math.h>

class Point
{
public:
  Point(double xc, double yc) :
    x(xc), y(yc)
  {
  }
  double distance(const Point& other) const;

  double x;
  double y;
};

double Point::distance(const Point& other) const
{
  double dx = x - other.x;
  double dy = y - other.y;
  return sqrt(dx * dx + dy * dy);
}
}}}

= Coding hints = #code

== Some hints on good code vs. bad code == #code-good-bad

=== end of stream checking === #code-good-bad_eof

 Using
 {{{
    std::inputstream in;
    while (!in.eof()) {
      ..
    }
 }}}
 is bad. Rather one should use
 {{{
    std::inputstream in;
    while (in.getline(...)) {
      ..
    }
 }}}
 or
 {{{
    std::inputstream in;
    for(int j; in >> j;;) {
      ..
    }
 }}}
 or
 {{{
    std::inputstream in;
    in >> j;
    if (in.fail())
     ..
 }}}
 This involves some extra typing but ensures that in case of faulty streams the error is properly pointed at.

=== Use of new/delete, return === #code-good-bad_new-delete 

The new and delete statements are written without brackets, they are __not__ functions, i.e.
{{{
  new pointer;
  new array[3];
  delete pointer;
  delete[] array;
}}}

=== Use of return === #code-good-bad-return

The return statements should look like this
{{{
 return bar;
 return (foo && bar);
}}}

and __not__ like

{{{
 return (bar);
 return(foo);
}}}

=== Specific (initial) values of variables === #code-good-bad-limits

In general __all__ variables __always__ have to be initialized (we don't care about the extra tic, even if operating system guarantees zero as default memory value).

If they have to be set to some very small or very big value, use std::numeric_limits
{{{
  double smalldouble = std::numeric_limits<double>::min();
  double largedouble = std::numeric_limits<double>::max();
}}}
Also remember that there are also ::infinity() and alikes to set an illegal value which can be checked.

=== Make use of declaring member variables and functions const === #code-good-bad-const-members

We want to have a clean interface. Hence, it is vital to state in the interface that a function does not change the internal state of a class instance. If so, make it __const__. 

The same holds for variables. If they are set in the constructor and only read afterwards, make them __const__.

''Note:'' const variables are tricky with ''[http://www.boost.org/libs/serialization serialization]'', but in this specific case it is allowed to use '''const_cast<>()''' to allow writing a const member variable outside the constructor.

''Note:'' If a function is ''const in nature'' but modifies a very specific variable (specific to the function but needs to be contained in the class scope, e.g. a counter how often the function has been called), make it __mutable___.

=== Use forward declarations === #code-good-bad-limits-forward-declarations

Whenever possible __use forward declarations__ in header files. They are ''vital in reducing compilation times''. Remember that the preprocessor first compiles every include into the file subsequently served to the compiler. The larger this file becomes, the longer compilation takes.

If a function defined in a header file just has the parameter as a reference or as pointer, don't add the include but only the forward declaration in the header file.
{{{
// some header file

class MightyClass;

class SmallClass {
  ...
  void foo(MightyClass &_m);
  ...
};