Warning, /education/labplot/src/doc/coding_style.dox is written in an unsupported language. File is not indexed.

 /**\page coding_style Coding Style
 
 The following rules are not used everywhere (yet), but are intended as guidelines for new code and eventually
 old code should be adapted as well. They apply to C++ and C code. The standards are C++11 and C99.
 
 \section files Files
 
 - Files use Unix-style line endings ('\\n').
 - C++ source files use “.cpp” as extension, C source code use "*.c" and header files use “.h”.
 - The code is documented using Doxygen comments which are placed in the source files, not the header files.
 - Every file should be named exactly like the class inside and there should be only one class per file, with the exception of really short classes.
 Very short classes can be bundled in one file which then is named using all lower case letters.
 
 \section identifier Identifier names
 
 - Class names start with a capital letter and use CamelCase, acronyms in class names are use like normal words. Example: MySuperHtmlToPdfConverter
 - Function/method names start with a lower case letter and use CamelCase Example: doSomethingImportant()
 - Variable/object names start with a lower case letter and use CamelCase, underscores are used for special prefixes only. Example: numberOfPoints
 - Private class member variables are prefixed with “m_” to distinguish them easily. d-pointer and UI-widgets are called d and ui, respectively, i.e. without prefix.
 - Property access methods use Qt style: property() and setProperty(), except for boolean properties (isVisible(), hasChanged()). Accessor functions (getter/setter) can be done using macros.
 - Avoid abbreviations, except for local counters and temporaries whose purpose is obvious.
 
 \section indent Indentation, spacing and line breaks
 
 - Tabs are used for indentation because they allow everyone to choose the indentation depth for him/herself.
 - Try to keep lines shorter than 100 characters, inserting line breaks as necessary and indent the following lines to improved readability.
 - included headers should be in order: own header, local header, Qt/KDE header, system header, extern header
 - Opening braces (‘{‘) are placed behind the statement and are preceded by a space. This also goes for function implementations, class, struct and namespace declarations, which are exceptions in other coding styles. Example:
 @code
     void MyClass::doSomething() {
             if (condition) {
                     ...
             }
             ...
     }
 @endcode
 - Opening brackets (‘(‘) are preceded by a space in for/switch/if/while statements, but not for function calls.
     Example:
 @code
     if (condition) {
         doSomething(myData);
         ...
     }
 @endcode
 - For pointers or references, use a single space after ‘*’ or ‘&’ (i.e. specifier is bound to the data type not the name). Example:
 @code
     void doSomething(int* dataPointer, const QString& name);
     ... = static_cast(...)
 @endcode
     “public” and namespace enclosures are not indented. Example:
 @code
     class MyClass: public QObject {
     public:
         void doSomething();
 @endcode
     “case” of switch is not indented. “default” should be present only if data type is not an enum. Example:
 @code
     switch (condition) {
     case 1:
         handleCaseOne();
         break;
     case 2: {
         int i=0;
         ...
         break;
     }
     ...
     default:
         ...
     }
 @endcode
 - Each comma in a function call or semicolon in a for statement is followed by a space character; no space before the first and after the last argument. Example:
 @code
     for (int i = 0; i < 10; i++) {
         ...
         doSomething(arg1, arg2, arg3);
     }
 @endcode
     "else" (and "catch" if it is ever used) is put after the closing brace like this: "} else {"
 - Use as many brackets in conditions/math terms as you see fit for optimum readability. All operators ('=', '==', '<', '+', '-', '<<', etc.) and castings should always be surrounded by spaces. Examples:
 @code
     foo/2 + bar/4 + baz/3
     for (int i = 0; i < bar+1; i++)
     var = (foo - 1) + (bar - 2) + (baz - 3)
     char *s = (char*) malloc(LENGTH * sizeof(char));
 @endcode
 - enum and structs should be defined first in a class. use strongly typed enums ("enum class")
 - parameter names in a method definition should only be used to explains the usage of the parameter
 - In SIGNAL() and SLOT() macros, use as little whitespace as possible. This gives a little speed up since Qt does not have to normalize the signal/slot name.
 
 \section constructs Usage of specific constructs
 
 * Qt version features can be checked with "#if QT_VERSION >= 0x050403" (meaning Qt 5.4.3)
 * For integer data types int is preferred for indices and normal numbers, size_t for big, unsigned values and quint64 for datetime values. Use double (qreal) as floating point type.
         Compare floating point numbers with qFuzzyCompare() or qFuzzyIsNull().
 * Use C++ casting (static_cast, const_cast, dynamic_cast) and qobject_cast in Qt classes since they include checks
         see https://en.wikibooks.org/wiki/C%2B%2B_Programming/Programming_Languages/C%2B%2B/Code/Statements/Variables/Type_Casting
 * Use Qt container instead of STL container
         https://marcmutz.wordpress.com/effective-qt/containers/
         See also "Hands-On High Performance Programming with Qt5"
 * QVector: size() instead of count(),  resize() for simple types (bool, int, double) and reserve() else, use at() for ro access, to release memory use squeeze()
 * QString: https://wiki.qt.io/Using_QString_Effectively, https://forum.qt.io/topic/78540/qstringliteral-vs-qlatin1string/3, https://www.qt.io/blog/2014/06/13/qt-weekly-13-qstringliteral, https://woboq.com/blog/qstringliteral.html
 * Use range-based loops instead of foreach/Q_FOREACH (but avoid detach: https://www.kdab.com/goodbye-q_foreach/ - "Avoid Detach")
         https://www.kdab.com/goodbye-q_foreach/
 * The 'auto' keyword should be used in range-based loops and for variables initialized by casting or with the 'new' operator but only for non-basic types (int,double,Spreadsheet). Do not omit '*', '&' and 'const' to keep readability.
 * use smart pointers unique_ptr when possible and shared_ptr otherwise.
 * Avoid const pass-by-value parameters in function declarations. Still make the parameter const in the same function's definition if it won't be modified.
 * Use the 'override' specifier when overriding virtual functions from the base class
         http://en.cppreference.com/w/cpp/language/override
 * Use braces to enclose a single statement only for readability
 * In C++ nullptr should be used instead of bug-prone NULL and 0.
 * Use brace initializing for default values (but avoid default initialization like bool/int/double = false/0/0.0) and use them when reading config settings: see TextLabel::init()
         Examples: int{0}, double{0.0}, color{Qt::black}, font{"Times", 12}, point{QPoint(1, 1)}
         Run time settings like QApplication::desktop()->physicalDpiX() can be used too.
         Attention: v{2} initializes a vector to one element of value 2, use v{0., 0.} for two values initalized to 0.
 * Direct brace initialization (QString fileName{name};) is preferred over assignment initialization. (see also https://www.learncpp.com/cpp-tutorial/variable-assignment-and-initialization/)
 * #include <...> vs. #include "...": Include headers from external libraries using angle brackets (as in #include <QDebug>) and headers from LabPlot/SciDAVis using double quotes (as in #include "core/AbstractAspect.h"). Rationale: Headers of external libraries are never in the same directory as the including file, so it makes sense to use the angle bracket form (which searches only in directories specified using -I). If you work with a build system that does not include the current source directory, or disable CMAKE_INCLUDE_CURRENT_DIR, then all angle-bracket-includes referencing LabPlot/SciDAVis headers will break. Excluding the current directory from -I dirs may be desirable one day when using a new library or a new version of a library containing a header file with the same name as one of our headers.
 * Use DEBUG() macro for debugging code when possible and QDEBUG() only for special Qt data types. DEBUG() works on all supported systems.
 @code
         QString string;
         DEBUG(" string : " << STDSTRING(string))
 @endcode
 * Use Qt functions for user messages: qDebug(), qWarning(), qCritical(), qFatal(). Check conditions with Q_ASSERT(cond) or Q_ASSERT_X(cond, where, what) and pointers with Q_CHECK_PTR(ptr).
 * Numeric limits should be using cmath +/-INFINITY and NAN for floating point types and C++ +/-std::numeric_limits<T>::min() & +/-std::numeric_limits<T>::max() for all types
 * Import C header (from GSL etc.) with extern statement. We use "std::" prefix (C++11) and try to use c-header <cmath> (std::abs(), DBL_MAX -> std::numeric_limits<double>::max(), std::round(), max() -> std::max(), std::isfinite(), std::isnan(), std::isinf()). Example:
 @code
     extern "C" {
     #include <gsl/gsl_version.h>
     }
 
     if (std::isnan(x)) {
         ...
     }
 @endcode
 * Use QOverload<int>::of instead of (for instance) static_cast<void (QComboBox::*)(int)> in connect()
 \section links Links
 
 Apart from that, the following links are recommended as guidelines for the coding style:
 
 https://wiki.qt.io/Qt_Coding_Style
 
 https://wiki.qt.io/Coding_Conventions
 
 https://techbase.kde.org/Policies/Frameworks_Coding_Style
 
 https://community.kde.org/Policies/Library_Code_Policy
 
 https://techbase.kde.org/Development/Tutorials/Common_Programming_Mistakes
 
 https://community.kde.org/Krita/C%2B%2B11
 */