Skip to content
Snippets Groups Projects
Commit df07f87a authored by Christoph Grüninger's avatar Christoph Grüninger
Browse files

[handbook] Add how to use headercheck only for one header.

Some other improvements.


git-svn-id: svn://svn.iws.uni-stuttgart.de/DUMUX/dumux/trunk@10715 2fb0f335-1f38-0410-981e-8018bf24f1b0
parent 134f5f7a
No related branches found
No related tags found
No related merge requests found
......@@ -20,35 +20,39 @@ been written by oneself.
\begin{itemize}
\item Comments: they are helpful! Please document freely what each part of your code does.
\item all comments / documentation is in English
\item Variables: Names for variables should only consist of letters and digits. The first letter should be a lower case one. If your variable names consists of several words, then the first letter of each new word should be capital. As we decided on the only exception are the begin and end methods.
\item Variables should be named as self-explaining as possible: especially abbreviations should be avoided (saturation in stead of S)
\item Variables: Names for variables should only consist of letters and digits. The first
letter should be a lower case one. If your variable names consists of several words, then
the first letter of each new word should be capital. As we decided on the only exception
are the begin and end methods.
\item Variables should be named as self-explaining as possible: especially abbreviations
should be avoided (saturation in stead of S)
\item Method parameters which are not self-explanatory should always
have a meaningful comment a at calling sites. Example:
\begin{lstlisting}[style=DumuxCode]
localResidual.eval(/*includeBoundaries=*/true);
\end{lstlisting}
\item Private Data Variables: Names of private data variables end with an underscore and are the only variables that contain underscores.
\item Typenames: For typenames, the same rules as for variables apply. The only difference is that the first letter should be a capital one.
\item Type names: For type names, the same rules as for variables apply. The only difference is that the first letter should be a capital one.
\item Macros: The use of preprocessor macros is strongly discouraged. If you have to use them for whatever reason, please use capital letters only.
\item The Exlusive-Access Macro: Every header file traditionally begins with the definition of a preprocessor constant that is used to make sure that each header file is only included once. If your header file is called 'myheaderfile.hh', this constant should be DUNE\_MYHEADERFILE\_HH.
\item Files: Filenames should consist of lower case letters exclusively. Header files get the suffix .hh, implementation files the suffix .cc
\item The Exclusive-Access Macro: Every header file traditionally begins with the definition of a preprocessor constant that is used to make sure that each header file is only included once. If your header file is called 'myheaderfile.hh', this constant should be DUNE\_MYHEADERFILE\_HH.
\item Files: File names should consist of lower case letters exclusively. Header files get the suffix .hh, implementation files the suffix .cc
\end{itemize}
\item Documentation:
\Dumux, as any software project of similar complexity, will stand and fall with the quality of its documentation.
Therefore it is of paramount importance that you document well everything you do! We use the doxygen system to extract easily-readable documentation from the source code. Please use its syntax everywhere. In particular, please comment \textbf{all}
Therefore it is of paramount importance that you document well everything you do! We use the Doxygen system to extract easily-readable documentation from the source code. Please use its syntax everywhere. In particular, please comment \textbf{all}
\begin{itemize}
\item Method Parameters (in / out)
\item Template Parameters
\item Return Values
\item Exceptions thrown by a method
\end{itemize}
Since we all know that writing documentation is not well-liked and is frequently defered to some vague
'next week', we herewith proclaim the Doc-Me Dogma . It goes like this: Whatever you do, and in whatever hurry you
Since we all know that writing documentation is not well-liked and is frequently deferred to some vague
'next week', we herewith proclaim the Doc-Me Dogma. It goes like this: Whatever you do, and in whatever hurry you
happen to be, please document everything at least with a {\verb /** $\backslash$todo Please doc me! */}. That way at least the absence
of documentation is documented, and it is easier to get rid of it systematically.
\item Exceptions:
The use of exceptions for error handling is encouraged. Until further notice, all exceptions thrown are DuneEx.
The use of exceptions for error handling is encouraged. Until further notice, all exceptions thrown are Dune exceptions.
\item Debugging Code:
Global debugging code is switched off by setting the symbol NDEBUG. In particular, all asserts are
Global debugging code is switched off by setting the macro NDEBUG or the compiler flag -DNDEBUG. In particular, all asserts are
automatically removed. Use those asserts freely!
\end{itemize}
......@@ -71,6 +71,6 @@ How to set the svn attributes:
\end{itemize}
Commit the changes for example in the command line with \verb+svn commit -m+ to the repository. It is also possible to use wildcards, e.\,g., if you want to ignore all vtu-files in your application folder in dumux-devel set \verb+FILETOIGNORE+ to \verb+'*.vtu'+. Remember that such an ignore is only allowed in dumux-devel and not in the stable dumux.
\textbf{Second}: It is good practice that every header includes everything it uses by itself and does not rely on the includes from headers that are included by themselves. This can be tested with \texttt{make headercheck} and should be done before committing to stable dumux.
\textbf{Second}: It is good practice that every header includes everything it uses by itself and does not rely on the includes from headers that are included by themselves. This can be tested with \texttt{make headercheck} and should be done before committing to stable dumux. To test a specific header, use \texttt{make} \texttt{headercheck} \texttt{HEADER=} and add the header's path.
\textbf{Third}: Run \texttt{make doc} in the \texttt{\$DUMUX\_ROOT} directory to generate the class documentation by Doxygen. Have a look into \texttt{\$DUMUX\_ROOT/doc/doxygen/doxyerror.log} whether one of your files have errors or are causing warnings. Please fix them.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment