From: bangerth Date: Wed, 26 Nov 2008 13:32:59 +0000 (+0000) Subject: Touch up in a few places. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4002a48f3ac5dfcfbe0e96edefe54b91b2e2b48a;p=dealii-svn.git Touch up in a few places. git-svn-id: https://svn.dealii.org/trunk@17750 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/doxygen/headers/coding_conventions.h b/deal.II/doc/doxygen/headers/coding_conventions.h index 2f9a435d5a..4ad5edc9ac 100644 --- a/deal.II/doc/doxygen/headers/coding_conventions.h +++ b/deal.II/doc/doxygen/headers/coding_conventions.h @@ -2,7 +2,7 @@ // $Id: fe.h 12032 2006-01-15 00:41:50Z wolf $ // Version: $Name$ // -// Copyright (C) 1998, 2007 by the deal.II authors +// Copyright (C) 1998, 2007, 2008 by the deal.II authors // // This file is subject to QPL and may not be distributed // without copyright and license information. Please refer @@ -42,10 +42,12 @@ The following are the general rules we attempt to follow: visibly enough.
  • Whenever an integer variable can only assume nonnegative values, - it has to be marked as unsigned.
  • + it is 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 + const, even if passed by value. Generally, we mark input parameters as + const. This aids as an additional documentation tool to clarify the + purpose of a parameter and lets the compiler issue warnings if such a parameter variable is changed, which is often either involuntarily or poor style.
  • @@ -55,17 +57,13 @@ The following are the general rules we attempt to follow:
  • %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 +
  • 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 + than writing them into the code 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).
  • + readability of code.
  • The layout of class declarations is the following: first the block of public functions, beginning with the constructors, then @@ -82,9 +80,10 @@ The following are the general rules we attempt to follow:
  • 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.
  • + are good reasons to change this order. (The most common reason is trailing + input parameters with default default values.) -
  • Exceptions are used for internal parameter checking and for +
  • 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 @@ -92,7 +91,7 @@ The following are the general rules we attempt to follow:
  • 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. + use lowercase letters and underscores to separate 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.