User Tools

Site Tools


coding_style

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
coding_style [2016/03/10 12:27] jmgrcoding_style [2016/03/14 12:37] – [Code separation] jmgr
Line 26: Line 26:
 | member variable | m_someExample | | | member variable | m_someExample | |
 | global variables | gSomeExample | should be avoided | | global variables | gSomeExample | should be avoided |
-| function | someExample() | |+| function | someExample() | function names should begin with a verb: computeMap(), displayWindow() |
 | member function | someExample() | | | member function | someExample() | |
 | getter function | name() | not getName(), Qt convention | | getter function | name() | not getName(), Qt convention |
Line 33: Line 33:
 | template parameter | SomeExample | | | template parameter | SomeExample | |
  
-Never use abbreviations in names, having long names is not an issue: all IDEs have an auto-completion feature.+**Never use abbreviations in names, having long names is not an issue: all IDEs have an auto-completion feature.**
 <code cpp> <code cpp>
 // Bad // Bad
Line 48: Line 48:
     //...     //...
 } }
 +</code>
 +
 +**Prefer using meaningful names instead of "one letter" names like i,j,k.**
 +<code cpp>
 +// Bad
 +for(int i = 0; i < ducks.size(); ++i)
 +{
 +    //...
 +}
 +
 +// Good
 +for(int duckIndex = 0; duckIndex < ducks.size(); ++duckIndex)
 +{
 +    //...
 +}
 +</code>
 +
 +**Variables representing GUI elements should be suffixed by their type**
 +<code cpp>
 +// Bad
 +QPushButton *exitApplication;
 +QLabel *duckCount;
 +
 +// Good
 +QPushButton *exitApplicationPushButton;
 +QLabel *duckCountLabel;
 </code> </code>
 ===== Code files ===== ===== Code files =====
Line 53: Line 79:
 ==== Code separation ==== ==== Code separation ====
  
-Generally speaking, each class/struct should have its declaration in one file (header) and its definition in another file (source file). If a class/struct is very small then it can be contained in a header, for example if it only contains variables and no functions. Qt specific: note that QObject/QWidget-based classes have to have their own header file in order to the MOC (Qt'meta compiler) to find them. +Generally speaking, each class/struct should have its declaration in one file (header) and its definition in another file (source file). If a class/struct is very small then it can be contained in a header, for example if it only contains variables and no functions. Qt specific: note that QObject/QWidget-based classes have to have their own header file in order to the [[http://doc.qt.io/qt-5/moc.html|moc]] (Qt'Meta-Object Compiler) to find them.
 ==== Naming ==== ==== Naming ====
  
Line 85: Line 110:
 This feature in implemented in all known compilers and is both easier to use and foolproof. It has not been accepted into the C++ standard because of some particular cases, like having source files on multiple "remote mounts": https://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard. This feature in implemented in all known compilers and is both easier to use and foolproof. It has not been accepted into the C++ standard because of some particular cases, like having source files on multiple "remote mounts": https://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard.
  
-====== Examples ====== 
  
-<code cpp> 
-#include <string> 
-#include <memory> 
- 
-// An entity semantic class 
-class MyExampleClass final 
-{ 
-public: 
-    // This constructor is explicit to prevent something like this: MyExampleClass test = "some text"; 
-    explicit MyExampleClass(const std::string &myString): 
-        m_myVar{52}, 
-        m_myString{myString} 
-    { 
-    } 
- 
-    // Entity semantic: always forbid copy & assignment 
-    MyExampleClass(const MyExampleClass &) = delete; 
-    MyExampleClass &operator=(const MyExampleClass &) = delete; 
- 
-private: 
-    // Variables are always at the end, because they represent an implementation detail 
-    int m_myVar{42}; 
-    std::string m_myString{"value"}; 
-}; 
- 
-// A value semantic class 
-class MyVector final // Always final: a value semantic class should *never* be inherited from 
-{ 
-public: 
-    // We want to use the default implementation (wich is faster than anything we can do) 
-    MyVector() = default; 
- 
-    MyVector(const MyVector &other): 
-        m_x(other.m_x), 
-        m_y(other.m_y) 
-    { 
-    } 
- 
-    MyVector &operator=(MyVector other) 
-    { 
-        std::swap(m_x, other.m_x); 
-        std::swap(m_y, other.m_y); 
- 
-        return *this; 
-    } 
- 
-private: 
-    // m_x and m_y are initialized with the default value for the type int: 0 
-    // unless the initializer list in a constructor decides otherwise 
-    int m_x{}; 
-    int m_y{}; 
-}; 
- 
-void test() 
-{ 
-    // I use scopes "{}" here to limit where my variables live and are accessible 
-    { 
-        // Allocation on the stack (fast) 
-        MyExampleClass myExampleClass{"some text"}; 
-        // myExampleClass is destroyed here 
-    } 
-    { 
-        // Allocation on the heap (slower, allows polymorphism) 
-        std::unique_ptr<MyExampleClass> myExampleClass{std::make_unique<MyExampleClass>("some text")}; 
-        // Or (with auto) 
-        auto myExampleClass{std::make_unique<MyExampleClass>("some text")}; 
-        // myExampleClass is destroyed here (thanks to the smart pointer) 
-    } 
-} 
-</code> 
coding_style.txt · Last modified: 2023/04/25 16:52 by 127.0.0.1