StarMirror/styleguide
1
0
Fork 0
mirror of https://github.com/google/styleguide.git synced 2024-03-22 13:11:43 +08:00
Code Issues Projects Releases Wiki Activity

Merge pull request #699 from zetafunction/moo

Browse Source 
Update C++ style guide.
This commit is contained in:
Titus Winters 2022-07-06 17:16:24 -04:00 committed by GitHub
commit e8808406ea
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 24 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
cppguide.html
View File

@ -1706,7 +1706,7 @@ following order:</p>
<ol> <ol>
<li>Types and type aliases (<code>typedef</code>, <code>using</code>, <li>Types and type aliases (<code>typedef</code>, <code>using</code>,
<code>enum</code>, nested structs and classes)</li> <code>enum</code>, nested structs and classes, and <code>friend</code> types)</li>
<li>Static constants</li> <li>Static constants</li>
@ -2896,6 +2896,17 @@ compiler and architecture.</p>
<p class="decision"></p> <p class="decision"></p>
<p>
The standard library header <code>&lt;cstdint&gt;</code> defines types
like <code>int16_t</code>, <code>uint32_t</code>,
<code>int64_t</code>, etc. You should always use
those in preference to <code>short</code>, <code>unsigned
long long</code> and the like, when you need a guarantee
on the size of an integer. Of the C integer types, only
<code>int</code> should be used. When appropriate, you
are welcome to use standard types like
<code>size_t</code> and <code>ptrdiff_t</code>.</p>
<p>We use <code>int</code> very often, for integers we <p>We use <code>int</code> very often, for integers we
know are not going to be too big, e.g., loop counters. know are not going to be too big, e.g., loop counters.
Use plain old <code>int</code> for such things. You Use plain old <code>int</code> for such things. You
@ -4459,23 +4470,20 @@ declaration:</p>
are provided in `backticks`, then code-indexing are provided in `backticks`, then code-indexing
tools may be able to present the documentation better.</li> tools may be able to present the documentation better.</li>
<li>For class member functions: whether the object <li>For class member functions: whether the object remembers
remembers reference arguments beyond the duration of reference or pointer arguments beyond the duration of the method
the method call, and whether it will free them or call. This is quite common for pointer/reference arguments to
not.</li> constructors.</li>
<li>If the function allocates memory that the caller <li>For each pointer argument, whether it is allowed to be null and what happens
must free.</li> if it is.</li>
<li>Whether any of the arguments can be a null <li>For each output or input/output argument, what happens to any state that argument
pointer.</li> is in. (E.g. is the state appended to or overwritten?).
<li>If there are any performance implications of how a </li><li>If there are any performance implications of how a
function is used.</li> function is used.</li>
</ul>
<li>If the function is re-entrant. What are its
synchronization assumptions?</li>
</ul>
<p>Here is an example:</p> <p>Here is an example:</p>
@ -4946,7 +4954,8 @@ void Circle::Rotate(double) {}
<p>Attributes, and macros that expand to attributes, appear at the very <p>Attributes, and macros that expand to attributes, appear at the very
beginning of the function declaration or definition, before the beginning of the function declaration or definition, before the
return type:</p> return type:</p>
<pre>ABSL_MUST_USE_RESULT bool IsOk(); <pre> ABSL_ATTRIBUTE_NOINLINE void ExpensiveFunction();
[[nodiscard]] bool IsOk();
</pre> </pre>
<h3 id="Formatting_Lambda_Expressions">Lambda Expressions</h3> <h3 id="Formatting_Lambda_Expressions">Lambda Expressions</h3>