C++ style guide: Difference between revisions

Jump to navigation Jump to search
2,381 bytes added ,  24 August 2016
import more text from the manual
(import more text from the manual)
Line 14: Line 14:
We use spaces for indentation. Absolutely do not use tabs in your code.
We use spaces for indentation. Absolutely do not use tabs in your code.
You should probably set your editor to emit spaces when you hit the tab key.
You should probably set your editor to emit spaces when you hit the tab key.
When indenting, indent the statement after control
structures (like {{codeline|if}}, {{codeline|while}}, etc.).  If there
is a compound statement, indent ''both'' the curly braces and the
body of the statement (so that the body gets indented by ''two''
indents).  This format is known as "GNU style" and is an option for
some code formatting tools.  Example indenting:
<pre>
if (have_args)
  {
    idx.push_back (first_args);
    have_args = false;
  }
else
  idx.push_back (make_value_list (args, arg_nm, tmp));
</pre>
If you have nested {{codeline|if}} statements, use extra braces for extra
clarification.
Split long expressions in such a way that a continuation line starts
with an operator rather than identifier.  If the split occurs inside
braces, continuation should be aligned with the first char after the
innermost braces enclosing the split.  Example:
<pre>
SVD::type type = ((nargout == 0 || nargout == 1)
                  ? SVD::sigma_only
                  : (nargin == 2) ? SVD::economy : SVD::std);
</pre>
=== Non indenting whitespace ===
Consider putting extra braces around a multi-line expression to make it
more readable, even if they are not necessary.  Also, do not hesitate to
put extra braces anywhere if it improves clarity.
The negation operator is written with a space between the operator
and its target, e.g., {{codeline|! A}}.


=== Line Length ===
=== Line Length ===
Line 20: Line 60:
readability in the widest range of environments.  This is inherited from
readability in the widest range of environments.  This is inherited from
the [https://www.gnu.org/prep/standards/standards.html#Formatting GNU Coding Standards].
the [https://www.gnu.org/prep/standards/standards.html#Formatting GNU Coding Standards].
=== Function headers ===
Format function headers like this:
<pre>
static bool
matches_patterns (const string_vector& patterns, int pat_idx,
                  int num_pat, const std::string& name)
</pre>
The return type of the function and any modifiers are specified on the first
line.  The function name on the second line should start in column 1, and
multi-line argument lists should be aligned on the first char after the open
parenthesis.  You should put a space before the left open parenthesis and after
commas, for both function definitions and function calls.


=== Namespace ===
=== Namespace ===
Line 63: Line 119:
}
}
</pre>}}
</pre>}}
== Naming ==
Use lowercase names if possible.  Uppercase is acceptable for variable
names consisting of 1-2 letters.  Do not use mixed case names.


== Header Files ==
== Header Files ==
Line 98: Line 160:
Header files should not use any "#if defined (HAVE_FEATURE)" conditionals.  This is not quite true yet, but we are almost there.  '''No new conditionals may be added.'''
Header files should not use any "#if defined (HAVE_FEATURE)" conditionals.  This is not quite true yet, but we are almost there.  '''No new conditionals may be added.'''


== Other C++ features ==
== C++ features ==


=== C++11 ===
=== C++11 features ===


C++11 features are generally allowed. Check if the feature you want to
C++11 features are generally allowed. Check if the feature you want to
use has been already used.  If not, ask on the mailing list.
use has been already used.  If not, ask on the mailing list.


==== auto ====
=== std::string ===
 
When an empty string is required, use @qcode{""}, rather than creating an empty
string object with @code{std::string ()}.
 
=== auto ===


Use of {{codeline|auto}} is allowed only where it helps readability
Use of {{codeline|auto}} is allowed only where it helps readability
Line 131: Line 198:
   // alternative code in its absence
   // alternative code in its absence
  #endif
  #endif
== Comments ==
=== FIXME notes ===
The preferred comment mark for places that may need further attention is
with {{codeline|FIXME:}} comments.

Navigation menu