From 828df9a98642a6fd4e0902cca2af00b29d48d4cc Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Thu, 13 Sep 2007 17:43:39 +0000 Subject: [PATCH] Move the coding conventions file into the doxygen directory git-svn-id: https://svn.dealii.org/trunk@15206 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/common/CodingConventions | 72 ------------ .../doc/doxygen/headers/coding_conventions.h | 104 ++++++++++++++++++ 2 files changed, 104 insertions(+), 72 deletions(-) delete mode 100644 deal.II/common/CodingConventions create mode 100644 deal.II/doc/doxygen/headers/coding_conventions.h diff --git a/deal.II/common/CodingConventions b/deal.II/common/CodingConventions deleted file mode 100644 index d3d5a9247b..0000000000 --- a/deal.II/common/CodingConventions +++ /dev/null @@ -1,72 +0,0 @@ -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 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< +
  • %Functions which return the number of something (number of cells, + degrees of freedom, etc) should start with n_*
  • + +
  • %Function which set a bit or flag should start with set_*; + functions which clear bits of flags should be named clear_*
  • + +
  • 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.
  • + +
  • Whenever an integer variable can only assume nonnegative values, + it has to be marked as unsigned.
  • + +
  • 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.
  • + +
  • Whenever a function does not change any of the member variable of + the embedding class/object, it should be marked as const.
  • + +
  • %Function and variable names may not consist of only one or two + letters, unless the variable is a pure counting index.
  • + +
  • Use the geometry information in GeometryInfo 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@<@ 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).
  • + +
  • 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. + +
  • 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.
  • + +
  • 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.
  • + +
  • Classes and types 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.
  • + +
  • Each class has to have at least 200 pages of documentation ;-)
  • + + + + */ -- 2.39.5