+++ /dev/null
-Here are some conventions for source code of the deal.II library:
-=================================================================
-
-1./ Functions which return the number of something (number of cells,
- degrees of freedom, etc) should start with n_*
-
-2./ Function which set a bit or flag should start with set_*;
- functions which clear bits of flags should be named clear_*
-
-3./ After each function, at least three empty lines are expected to
- enable better readability. One empty line occurs in functions to
- group blocks of code, two empty lines are not enough to distinguish
- visibly enough.
-
-4./ Whenever an integer variable can only assume nonnegative values,
- it has to be marked as unsigned.
-
-5./ Whenever an argument will not be changed, it should be marked
- const, even if it passed by value. This makes programs more readable
- and lets the compiler issue warnings if such a parameter variable is
- changed, which is often either involuntarily or poor style.
-
-6./ Whenever a function does not change any of the member variable of
- the embedding class/object, it should be marked as const.
-
-7./ Function and variable names may not consist of only one or two
- letters, unless the variable is a pure counting index.
-
-8./ Use the geometry information in GeometryInfo<dim> to get the
- number of faces per cell, the number of children per cell, the
- child indices of the child cells adjacent to face 3, etc, rather
- than writing them into the directly as 2*dim, (1<<dim) and
- {0,3}. This reduces the possibilities for errors and enhances
- readability of code. Unfortunately, the GeometryInfo mechanism
- was not invented right at the start of the program, so there are
- quite a lot of places where this rule is violated. Of you find
- such a place, fix it. We have set an amount of 1 cent per fixed
- place, payable by cheque when the deal.II project is considered
- finished by the author(s).
-
-9./ The layout of class declarations is the following: first the
- block of public functions, beginning with the constructors, then
- the destructors. If there are public member variables, these have
- to occur before the constructor. Public variables shall only be
- used if constant or unavoidable.
-
- After the public members, the protected and finally the private
- members are to be listed. The order is as above: first variables
- then functions.
-
- Exceptions shall be declared at the end of the public section
- before the non-public sections start.
-
-10./ If a function has both input and output parameters, usually the
- input parameters shall precede the output parameters, unless there
- are good reasons to change this order.
-
-11./ Exceptions are used for internal parameter checking and for
- consistency checks through the Assert macro. Exception handling
- like done by the C++ language (try/throw/catch) are used to
- handle run time errors (like I/O failures) which must be on
- in any case, not only in debug mode.
-
-12./ Classes generally are named using uppercase letters to denote
- word beginnings (e.g. TriaIterator) while functions and variables
- use lowercase letters and underscores to denote different words.
- The only exception are the iterator typedefs in Triangulation
- and DoFHandler (named cell_iterator, active_line_iterator, etc)
- to make the connection to the STL classes clear.
-
-13./ Each class has to have at least 200 pages of documentation ;-)
-