{"id":1981,"date":"2020-01-14T19:13:53","date_gmt":"2020-01-14T18:13:53","guid":{"rendered":"https:\/\/iww.inria.fr\/sed-sophia\/?p=1981"},"modified":"2020-01-14T19:13:53","modified_gmt":"2020-01-14T18:13:53","slug":"dtk-coding-style","status":"publish","type":"post","link":"https:\/\/iww.inria.fr\/sed-sophia\/dtk-coding-style\/","title":{"rendered":"dtk coding style"},"content":{"rendered":"<h2>Introduction<\/h2>\n<p>This document describes the recommended coding style for dtk. This style is not mandatory, but to have consistent formatting of the source code files it is recommended to make use of it.<\/p>\n<p>dtk coding style follows the <a href=\"https:\/\/wiki.qt.io\/Qt_Coding_Style\">Qt coding style<\/a>, with few differences desribed here after.<\/p>\n<h2>Rules<\/h2>\n<h3>Indentation<\/h3>\n<ul>\n<li>4 spaces<\/li>\n<li>no tab<\/li>\n<\/ul>\n<h3>Variable declaration<\/h3>\n<ul>\n<li>Declare each variable on a separate line<\/li>\n<li>Avoid abbreviations and meaningless names (<em>e.g.<\/em> &quot;a&quot;, &quot;rabarr&quot;, &quot;toto&quot;)<\/li>\n<li>Take useful names. No short names, except:\n<ul>\n<li>single character variable names can denote counters and<\/li>\n<li>temporary variables whose purpose is obvious.<\/li>\n<\/ul>\n<\/li>\n<li>Variable name are lower case and each part of the name is separated with underscore.<\/li>\n<li>Functions, methods and classes start with lower-case letter. Each consecutive word in their names start with an upper-case letter.<\/li>\n<li>typedef and acronyms are camel-cased (<em>e.g.<\/em> dtkMesherCgal rather than dtkMesherCGAL)<\/li>\n<\/ul>\n<p>Examples:<\/p>\n<pre><code class=\"language-cpp\">\/\/ wrong\ndtkSparseSolver *ss;\ndtkSparseMatrix *mtx;\n\n\/\/ correct\ndtkSparseSolver *sparse_solver;\ndtkSparseMatrix *sparse_matrix;<\/code><\/pre>\n<h3>Member variables<\/h3>\n<ul>\n<li>When using a d-pointer, the member variable declaration follows the above rules.<\/li>\n<li>When variables are declared directly as member of a class, their name is asked to start with the prefix <code>m_<\/code><\/li>\n<\/ul>\n<p>Examples:<\/p>\n<pre><code class=\"language-cpp\">\/\/ wrong\nclass dtkConcreteDummy\n{\nprivate:\n    int    _counter;\n    double value_;\n};\n\n\/\/ correct\nclass dtkConcreteDummy\n{\nprivate:\n    int    m_counter;\n    double m_value;\n};<\/code><\/pre>\n<h3>Member methods<\/h3>\n<ul>\n<li>Setter methods start with the prefix &#8216;set&#8217; in lower case.<\/li>\n<li>The getter methods do not start with &#8216;get&#8217;.<\/li>\n<li>When argument list is empty, the keyword <code>void<\/code> is used.<\/li>\n<li>Users are asked to group setter and getter methods in a consistent way by using <code>public<\/code> keyword as separator.<\/li>\n<\/ul>\n<p>Examples:<\/p>\n<pre><code class=\"language-cpp\">\/\/ wrong\nclass dtkConcreteDummy\n{\npublic:\n    void SetCounter(int counter);\n    double getValue();\n};\n\n\/\/ correct\nclass dtkConcreteDummy\n{\npublic:\n    void setCounter(int counter);\n\npublic:\n    double value(void);\n};<\/code><\/pre>\n<h3>Whitespaces<\/h3>\n<ul>\n<li>Use blank lines to group statements together<\/li>\n<li>Always use only one blank line<\/li>\n<li>Always use a single space after a keyword and before a curly brace:<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nif(foo){\n}\n\n\/\/ correct\nif (foo) {\n}<\/code><\/pre>\n<ul>\n<li>For pointers always use a single space between the type and the pointer symbol <code>*<\/code> but no space between <code>*<\/code> and the variable name<\/li>\n<li>For references, use no space between the type and the reference symbol <code>&amp;<\/code> but always a single space between <code>&amp;<\/code> and the variable name<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nchar* my_char;\nconst QString &amp;my_string;\n\n\/\/ correct\nchar *my_char;\nconst QString&amp; my_string;<\/code><\/pre>\n<ul>\n<li>Surround binary operators with spaces<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nfor (int i=0;i&lt;N;++i) {\n    dtkDebug() &lt;&lt; i;\n}\n\n\/\/ correct\nfor (int i = 0; i &lt; N; ++i) {\n    dtkDebug() &lt;&lt; i;\n}<\/code><\/pre>\n<ul>\n<li>No space after a cast<\/li>\n<li>Avoid C-style casts when possible<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nchar *block_of_memory = (char*) malloc(data.size());\n\n\/\/ correct\nchar *block_of_memory = reinterpret_cast&lt;char *&gt;(malloc(data.size()));<\/code><\/pre>\n<ul>\n<li>Do not put multiple statements on one line<\/li>\n<li>By extension, use a new line for the body of a control flow statement:<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nif (foo) bar();\n\n\/\/ correct\nif (foo) {\n    bar();\n}<\/code><\/pre>\n<h3>Braces<\/h3>\n<ul>\n<li>As a base rule, the left curly brace goes on the same line as the start of the statement.<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nif (true)\n{\n}\nelse\n{\n}\n\n\/\/ correct\nif (true) {\n} else {\n}<\/code><\/pre>\n<ul>\n<li>The rule differs for function implementations, class, struct and namespace declarations. In this case, the opening brace always starts on a line.<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">static void foo(int g)\n{\n    dtkDebug() &lt;&lt; \"foo: \" &lt;&lt; g;\n}\n\nclass dtkAbstractConcept\n{\n};<\/code><\/pre>\n<ul>\n<li>Use curly braces even when the body of a conditional statement contains only one line.<\/li>\n<\/ul>\n<p>Example:<\/p>\n<pre><code class=\"language-cpp\">\/\/ wrong\nif (true)\n    return true;\n\nfor (int i = 0; i &lt; 10; ++i)\n    dtkDebug() &lt;&lt; i;\n\n\/\/ correct\nif (true) {\n    return true;\n}\n\nfor (int i = 0; i &lt; 10; ++i) {\n    dtkDebug() &lt;&lt; i;\n}<\/code><\/pre>\n<h3>Parenthesis<\/h3>\n<ul>\n<li>Use parentheses to group expressions:<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\nif (a &amp;&amp; b || c)\n\n\/\/ correct\nif ((a &amp;&amp; b) || c)\n\n\/\/ wrong\na + b &amp; c\n\n\/\/ correct\n(a + b) &amp; c<\/code><\/pre>\n<h3>Switch statements<\/h3>\n<ul>\n<li>The case labels are in the same column as the switch<\/li>\n<li>Every case must have a break (or return) statement at the end or a comment to indicate that there&#8217;s intentionally no break, unless another case follows immediately.<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">switch (myEnum) {\ncase Value1:\n    doSomething();\n    break;\ncase Value2:\ncase Value3:\n    doSomethingElse();\n    \/\/ fall through\ndefault:\n    defaultHandling();\n    break;\n}<\/code><\/pre>\n<h3>Jump statements<\/h3>\n<ul>\n<li>Do not put <code>else<\/code> after jump statements<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ Wrong\nif (this_or_that) {\n    return;\n} else {\n    somethingElse();\n}\n\n\/\/ Correct\nif (this_or_that) {\n    return;\n}\nsomethingElse();<\/code><\/pre>\n<h3>Line breaks<\/h3>\n<ul>\n<li>Line size is not limited provided the code is readable.<\/li>\n<li>When breaking a line, commas go at the end of wrapped lines; operators start at the beginning of the new lines. An operator at the end of the line is easy to miss if the editor is too narrow.<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ Wrong\nif (long_expression +\n    other_long_expression +\n    another_long_expression) {\n}\n\n\/\/ Correct\nif (long_expression\n    + other_long_expression\n    + anothero_ther_long_expression) {\n}<\/code><\/pre>\n<h3>Qt includes<\/h3>\n<ul>\n<li>When including Qt classes, prefer the inclusion of the full module rather than the corresponding header alone.<\/li>\n<\/ul>\n<pre><code class=\"language-cpp\">\/\/ wrong\n#include &lt;QString&gt;\n\n\/\/ preferable\n#include &lt;QtCore&gt;<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"<p>Introduction This document describes the recommended coding style for dtk. This style is not mandatory, but to have consistent formatting of the source code files it is recommended to make use of it. dtk coding style follows the Qt coding style, with few differences desribed here after. Rules Indentation 4\u2026<\/p>\n<p> <a class=\"continue-reading-link\" href=\"https:\/\/iww.inria.fr\/sed-sophia\/dtk-coding-style\/\"><span>Continue reading<\/span><i class=\"crycon-right-dir\"><\/i><\/a> <\/p>\n","protected":false},"author":848,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,28,111],"tags":[119,43,20],"class_list":["post-1981","post","type-post","status-publish","format-standard","hentry","category-development-in-the-inria-teams","category-goodpractices","category-tools","tag-coding-style","tag-dtk","tag-qt"],"_links":{"self":[{"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/posts\/1981","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/users\/848"}],"replies":[{"embeddable":true,"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/comments?post=1981"}],"version-history":[{"count":13,"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/posts\/1981\/revisions"}],"predecessor-version":[{"id":1994,"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/posts\/1981\/revisions\/1994"}],"wp:attachment":[{"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/media?parent=1981"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/categories?post=1981"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/iww.inria.fr\/sed-sophia\/wp-json\/wp\/v2\/tags?post=1981"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}