Mercurial > hg > orthanc-book
view Sphinx/source/developers/coding-style.rst @ 1:1b6f12b8a54b
license in footer
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Fri, 22 Apr 2016 14:18:42 +0200 |
parents | 901e8961f46e |
children | 25fa874803ab |
line wrap: on
line source
.. highlight:: c++ Coding style ============ .. contents:: The developers of Orthanc should follow these `C++ Programming Style Guidelines <http://geosoft.no/development/cppstyle.html>`__, that are similar to the so-called "`BSD/Allman style <https://en.wikipedia.org/wiki/Indent_style#Allman_style>`__", with some adaptations that are described below. A compliant Eclipse formatter is `available in the Orthanc distribution <https://bitbucket.org/sjodogne/orthanc/src/default/Resources/EclipseCodingStyle.xml>`__. Licensing --------- Do not forget to include licensing information (GPLv3 with OpenSSL exception) in each ``.cpp`` and ``.h``. Tabulations ----------- No tab characters. Replace 1 tab by 2 spaces. Strengthened Rules ------------------ * Rule 31: Use ``COLOR_RED`` instead of ``Color::RED`` * Rule 34: Use the suffix ``.cpp`` * Rule 35: A single header file must contain a single public class * Rule 72: Use the Example 2 style (aka. Allman style, used by MSDN and Visual Studio):: while (!done) { doSomething(); done = moreToDo(); } Replaced Rules -------------- * Rule 6: The names of the methods are camel-case to move the coding style closer to that of the .NET framework. * Rule 36: * One-liners are always ok in a ``.h``, * High-performance code is also allowed but only with the inline keyword (the code being moved at the end of the header) * Rule 40: Use ``#pragma once`` in each header file (cf. `Wikipedia <http://en.wikipedia.org/wiki/Pragma_once>`__) * Rules 73 and 80: Use Visual Studio's default style that does not add two whitespaces in front of public, protected, private and case:: class SomeClass : public BaseClass { public: ... protected: ... private: ... }; Additional Rules ---------------- * Use C++ exceptions, avoid error codes. * Use the `RAII design pattern <http://en.wikipedia.org/wiki/RAII>`__ (Resource Allocation Is Initialization) wherever possible. * No C-style casting, use ``static_cast``, ``reinterpret_cast``, ``dynamic_cast`` and ``const_cast``. * Never use ``using namespace`` in header files (except inside inline implementations). * Complement to rule 20: ``Finalize`` is the complementary word to ``Initialize``. * Minimize the number of #include in header files. * Never use ``catch (...)``, except when protecting non-Orthanc code. * To ease unit testing, favor the `JavaBeans <http://en.wikipedia.org/wiki/Java_beans>`__ conventions: * Single constructor without argument, * Use getters/setters.