Differences

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

--- coding_style [2016/03/10 12:27] – jmgr
+++ coding_style [2016/03/11 12:36] – [Naming] jmgr
@@ Line 26: / Line 26: @@
 | member variable | m_someExample | |
 | global variables | gSomeExample | should be avoided |
-| function | someExample() | |
+| function | someExample() | function names should begin with a verb: computeMap(), displayWindow() |
 | member function | someExample() | |
 | getter function | name() | not getName(), Qt convention |
@@ Line 33: / Line 33: @@
 | 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>
 // 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 files =====
@@ Line 85: / Line 111: @@
 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>