You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

84 lines
3.1 KiB

namespace Magnum {
/** @page coding-style Coding style
@brief Coding style and best practices to preserve maintainability and
consistent style across whole project.
@tableofcontents
Please note that if you have a good excuse to either break the rules or modify
them, feel free to do it (and update this guide accordingly, if appropriate).
Nothing is worse than rule that hurts productivity instead of improving it.
This guide builds upon Corrade's coding style guide and extends it where
needed. You are encouraged to read it first:
- @ref corrade-coding-style
@section cpp C++ code
@subsection cpp-headers Headers
Headers shouldn't have `using` declarations inside them (unless there is good
excuse, see Magnum.h).
@subsection cpp-format Code format
@subsubsection cpp-naming Naming
When writing wrappers for OpenGL functions and defines, try to match the
original name as closely as possible, although expanding abbrevations (and
removing redundant prefixes) is encouraged.
@section documentation Doxygen documentation
@subsection documentation-commands Special documentation commands
Additionally to @c \@todoc and @c \@debugoperator (same as in Corrade), these
are defined:
@subsubsection documentation-commands-collisionoperator Physics collision operators
Out-of-class operators for collision in Physics namespace should be marked with
@c \@collisionoperator, e.g.:
@code
// @collisionoperator{Point,Sphere}
inline bool operator%(const Point& a, const Sphere& b) { return b % a; }
@endcode
They will appear as related functions within documentation of class for which
the operator is implemented (not of class in which the operator is
implemented), thus efficiently connecting the two classes together in the
documentation.
@subsubsection documentation-commands-extension Links to OpenGL extensions
If an OpenGL extension is referenced in the documentation, it should be done
with @c \@extension command:
@code
@extension{ARB,timer_query}
@endcode
It produces link to the specification of the extension in OpenGL registry,
e.g. @extension{ARB,timer_query}.
@subsubsection documentation-commands-requires Classes and functions requiring specific OpenGL version or extensions
If any class or function requires specific OpenGL version above 2.1, it should
be marked with appropriate command @c \@requires_glXX, where `XX` is version
number (e.g. `42` for OpenGL 4.2) or @c \@requires_extension for specific
extension which is not in any core OpenGL version. It should be used in
conjunction with @c \@extension command, if there is an extension providing
the same functionality. For example:
@code
@requires_GL33 Extension @extension{ARB,timer_query}
@endcode
If class is marked with the command, member and related functions shouldn't be
marked. On the other hand, if the version/extension is needed only by one
function, only the function should be marked. If the extension is needed only
for some functionality (not related to any member function), it should be
noted in the description.
All classes and functions using those commands are cross-referenced in page
@ref required-extensions.
*/
}