blocks|key|888729|text|方法和变量名称在公共命名方案中的一致性；在读取源代码时，我不太在意其他任何事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|888730|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Method and variable names in a common naming scheme for consistency; I don't tend to be bother much by anything else while reading source.

blocks|key|253064|text|没有制表符(允许更好地使用外部/其他工具)和为制表符插入固定空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253065|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No tabs (allows better use of external/other tools) and a fixed spaces inserted for tabs.

blocks|key|893115|text|如果您有超过一步的缩进，则需要花括号：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893116|if+(bla)+{
++for+(int+i+=+0;+i+<+n;+%2B%2Bi)
++++foo();
}|code-block|syntax|javascript|893117|这有助于使缩进与编译器如何看待代码保持一致。|893118|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Curly braces required if you have more than one step of indentation:

<pre><code>if (bla) {
 for (int i = 0; i &lt; n; ++i)
 foo();
}
</code></pre>

This helps to keep indentation in line with how the compiler sees the code.

blocks|key|888767|text|将功能保持在合理的大小。就我个人而言，我喜欢将功能保持在25行以下。当您可以将一个函数作为一个单元来使用时，它的可读性就会增强，而不必上下扫描，试图找出它是如何工作的。如果你不得不滚动阅读它，它会使事情变得更糟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|888768|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Keep functions to a reasonable size. Personally, I like to keep functions under 25 lines. Readability is enhanced when you can take a function in as a unit rather than having to scan up and down trying to figure out how it works. If you have to scroll to read it, it makes matters even worse.

blocks|key|253133|text|仅使用？：运算符，即|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253134|float+x+=+(y+>+3)+?+1.0f+:+-1.0f;|code-block|syntax|javascript|253135|是可以的，但这不是：|253136|float+x+=+foo(2+*+((y+>+3)+?+a+:+b)+-+1);|253137|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Only trivial use of the ? : operator, i.e.

<pre><code>float x = (y &gt; 3) ? 1.0f : -1.0f;
</code></pre>

is ok, but this is not:

<pre><code>float x = foo(2 * ((y &gt; 3) ? a : b) - 1);
</code></pre>

blocks|key|893174|text|按名称对类声明和定义中的函数进行排序。这使得在.cpp文件中找到它们变得更加容易。而且，它释放了你的思想，因为你不需要考虑把你的新功能放在哪里。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893175|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Sort functions in class declarations and definitions by name. This makes it easier to locate them in the .cpp file. Also, it frees your mind because you don't have to think about where to put your new function.

blocks|key|893182|text|确保您的编译器的警告级别设置得足够高(最好是/Wall)，这样它就会捕获以下愚蠢的错误：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893183|if+(p+=+0)|code-block|syntax|javascript|893184|当你真的是说|893185|if+(p+==+0)|893186|这样你就不需要使用更愚蠢的伎俩了，比如：|893187|if+(0+==+p)|893188|这降低了代码的可读性。|893189|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Make sure that your compiler's warning level is set high enough (/Wall preferably) so that it will catch silly mistakes like:

<pre><code>if (p = 0)
</code></pre>

when you really meant

<pre><code>if (p == 0)
</code></pre>

so that you don't need to resort to even sillier tricks like:

<pre><code>if (0 == p)
</code></pre>

which degrade the readability of your code.

blocks|key|888819|text|断言所有假设，包括临时假设，比如未实现的行为。断言函数的输入和退出条件，如果不是简单的话。断言所有非平凡的中间状态。您的程序绝不能在没有断言失败的情况下崩溃。您可以自定义断言机制，以忽略将来发生的事件。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|888820|对您希望发生的情况使用错误处理代码；对不应该发生的情况使用断言。错误处理通常检查错误的输入数据；断言检查代码中的错误。
如果使用错误处理代码来解决异常情况，则错误处理将使程序能够优雅地响应错误。如果断言是针对异常情况触发的，则纠正操作不仅仅是优雅地处理错误--纠正措施是更改程序的源代码、重新编译和发布软件的新版本。将断言视为可执行文档是一种很好的方法--您不能依赖它们来使代码工作，但它们可以比程序语言注释可以更积极地记录假设。|blockquote|888821|McConnell，史蒂夫。代码完成，第二版。微软出版社，2004年。第8章-防御性规划|ordered-list-item|888822|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Assert#Usage^0|0|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|F|7|V|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|W|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

<a href="http://en.wikipedia.org/wiki/Assert#Usage" rel="nofollow noreferrer">assert</a> all assumptions, including temporary assumptions, like unimplemented behavior. assert function entry and exit conditions if nontrivial. assert all nontrivial intermediate states. your program should never crash without an assert failing first. you can customize your assert mechanism to ignore future occurances.

<blockquote>
 Use error-handling code for conditions you expect to occur; use assertions for conditions that should never occur. Error handling typically checks for bad input data; assertions check for bugs in the code.
 
 If error-handling code is used to address an anomalous condition, the error handling will enable the program to respond to the error gracefully. If an assertion is fired for an anomalous condition, the corrective action is not merely to handle an error gracefully—the corrective action is to change the program's source code, recompile, and release a new version of the software. A good way to think of assertions is as executable documentation—you can't rely on them to make the code work, but they can document assumptions more actively than program-language comments can [1].
</blockquote>

<ol>
<li>McConnell, Steve. Code Complete, Second Edition. Microsoft Press © 2004. Chapter 8 - Defensive Programming</li>
</ol>

blocks|key|893200|text|任何控制语句的大括号。(感谢自己的经验，并通过阅读代码完整的v2而得到加强)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893201|//+bad+example+-+what+the+writer+wrote
if(+i+<+0+)+
++++printf(+"%25d\n",+i+);
++++%2B%2Bi;+//+this+error+is+_very_+easy+to+overlook!++

//+good+example+-+what+the+writer+meant
if(+i+<+0+)+{
++++printf(+"%25d\n",+i+);
++++%2B%2Bi;
}|code-block|syntax|javascript|893202|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Curly braces for any control statement. (Thanks to own experience and reinforced by reading Code Complete v2):

<pre><code>// bad example - what the writer wrote
if( i &lt; 0 ) 
 printf( "%d\n", i );
 ++i; // this error is _very_ easy to overlook! 

// good example - what the writer meant
if( i &lt; 0 ) {
 printf( "%d\n", i );
 ++i;
}
</code></pre>

blocks|key|253235|text|更喜欢雷伊。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|253236|STL的auto+(并在boost+&C%2B%2B0x中共享)指针可能会有所帮助。|253237|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization^0|3|2|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Prefer <a href="http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization" rel="noreferrer">RAII</a>.

STL's auto (and shared in boost &amp; C++0x) pointers may help.

blocks|key|253260|text|在可能的情况下使用引用而不是指针。这将防止持续的防御空检查。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253261|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Use references instead of pointers where possible. This prevents constant defensive NULL checks.

blocks|key|888854|text|使用皮棉工具--即。这将抓住许多“结构性”编码指南问题。指的是读到实际错误而不是风格/可读性问题的东西。(并不是可读性不重要，但它比实际错误要小)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|888855|示例，而不是要求这种样式：|888856|if+(5+==+variable)|code-block|syntax|javascript|888857|作为防止“意外分配”错误的一种方法，让林特找到它。|888858|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Use a lint tool - i.e. PC-Lint. This will catch many of the 'structural' coding guideline issues. Meaning things that read to actual bugs rather than style/readability issues. (Not that readability is not important, but it is less so than actual errors).

Example, rather than requiring this style:

<pre><code>if (5 == variable)
</code></pre>

As a way of preventing the 'unintended assignment' bug, let lint find it.

blocks|key|1252382|text|默认情况下使用const标识符。它们为读者/维护人员提供了保证，而且构建起来要比事后插入容易得多。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1252383|成员变量和方法都将声明为const，以及函数参数。const成员变量强制正确使用初始化程序列表。|1252384|这个规则的副作用:避免有副作用的方法.|1252385|-编辑|1252386|const成员变量似乎是个好主意；情况并不总是这样:它们有效地使任何对象不可变。这对于例如对向量进行排序就成了问题。|1252387|struct+A+{
++++const+int+i;
};

bool+operator<(const+A&+lhs,+const+A&+rhs)+{
++++return+lhs.i+<+rhs.i;
}

int+main()+{
++++std::vector<A>+as;
++++as.emplace_back(A{1});
++++std::sort(begin(as),+end(as));
}|code-block|syntax|javascript|1252388|错误信息：|1252389|...+note:+copy+assignment+operator+of+'A'+is+implicitly+deleted+because
field+'i'+is+of+const-qualified+type+'const+int'
...
in+instantiation+of+function+template+specialization+'std::sort<...>'
requested+here

++++std::sort(begin(as),+end(as));|1252390|entityMap^0|7|5|0|C|5|P|5|0|0|0|0|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|16|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|17|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|N|3|O|5|P|7|1B|8|@]|D|@]|E|$Q|R]]|$1|S|3|T|5|6|7|1C|8|@]|D|@]|E|$]]|$1|U|3|V|5|P|7|1D|8|@]|D|@]|E|$Q|R]]|$1|W|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|X|$]]

Use <code>const</code> identifiers by default. They provide guarantees for the reader/maintainer, and are way easier to build in than to insert afterwards.

Both member variables and methods would be declared <code>const</code>, as well as function arguments. <code>const</code> member variables enforce proper use of the initializer list.

A side-effect of this rule: avoid methods with side-effects.

------ EDIT

<code>const</code> member variables seemed like a good idea; this is not always the case: they effectively make any object immutable. This becomes problematic for e.g. sorting a vector.

<pre><code>struct A {
 const int i;
};

bool operator&lt;(const A&amp; lhs, const A&amp; rhs) {
 return lhs.i &lt; rhs.i;
}

int main() {
 std::vector&lt;A&gt; as;
 as.emplace_back(A{1});
 std::sort(begin(as), end(as));
}
</code></pre>

error message: 

<pre><code>... note: copy assignment operator of 'A' is implicitly deleted because
field 'i' is of const-qualified type 'const int'
...
in instantiation of function template specialization 'std::sort&lt;...&gt;'
requested here

 std::sort(begin(as), end(as));

</code></pre>

blocks|key|893268|text|禁止t[i]=i%2B%2B;+f(i%2B%2B,i);，等等，因为对于首先执行的内容没有(可移植的)保证。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|893269|entityMap^0|2|9|C|9|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Forbid <code>t[i]=i++;</code> <code>f(i++,i);</code>, and so on as there is no (portable) guarantees regarding what is executed first.

blocks|key|1252429|text|使用C%2B%2B强制转换而不是C强制转换|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1252430|用途：|1252431|static_cast|unordered-list-item|offset|length|style|CODE|1252432|const_cast|1252433|reinterpret_cast|1252434|dynamic_cast|1252435|但从来不像C风格的演员。|1252436|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性，等等。|BOLD|1252437|每个演员都有有限的力量。例如，如果您想删除const+(无论出于什么原因)，const_cast不会同时更改类型(这可能是一个很难找到的bug+)。|1252438|此外，这使得审阅者能够搜索它们，然后，如果需要的话，编码器可以对它们进行验证。|1252439|entityMap^0|0|0|0|B|0|0|A|0|0|G|0|0|C|0|0|0|1B|0|12|A|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|13|8|@$G|14|H|15|I|J]]|9|@]|A|$]]|$1|K|3|L|5|F|7|16|8|@$G|17|H|18|I|J]]|9|@]|A|$]]|$1|M|3|N|5|F|7|19|8|@$G|1A|H|1B|I|J]]|9|@]|A|$]]|$1|O|3|P|5|F|7|1C|8|@$G|1D|H|1E|I|J]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1G|8|@$G|1H|H|1I|I|U]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1J|8|@$G|1K|H|1L|I|J]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1M|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|10|$]]

<h2>Use C++ casts instead of C casts</h2>
use:
<ul>
<li><code>static_cast</code></li>
<li><code>const_cast</code></li>
<li><code>reinterpret_cast</code></li>
<li><code>dynamic_cast</code></li>
</ul>
but never C-style casts.
How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.
Each cast has limited powers. E.g., if you want to remove a const (for whatever reason), <code>const_cast</code> won't change the type at the same time (which could be a bug difficult to find).
Also, this enables a reviewer to search for them and then, the coder to justify them if needed.

blocks|key|253475|text|边注:不要强加SESE+(单入口单出口)(即不禁止超过一个return，使用break/continue/.)|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|253476|在C%2B%2B中，这是一个乌托邦，因为throw是另一个返回点。SESE在C语言和无异常语言中有两个优点：|253477|现在由C%2B%2B中的RAII成语巧妙地处理的资源的确定性发布，|unordered-list-item|253478|使函数更易于维护，这不应该成为关注的问题，因为函数必须保持简短(按照“一个函数，一个责任”的规则)。|253479|entityMap^0|T|6|12|5|18|8|0|G|5|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$]]|$1|K|3|L|5|J|7|Z|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|N|$]]

Side note: Do not impose SESE (Single Entry Single Exit) (i.e. do not forbid more than one <code>return</code>, the use of <code>break</code>/<code>continue</code>/...)

In C++, this is an utopia as <code>throw</code> is another return point. 
SESE had two advantages in C and exception-less languages:

<ul>
<li>the deterministic release of resources that is now neatly handled by the RAII idiom in C++,</li>
<li>making functions easier to maintain, that should not be a concern as the functions must be kept short (as specified by the rule of "one function, one responsibility")</li>
</ul>

blocks|key|888933|text|使用向量和字符串代替C样式数组和char+*|type|unstyled|depth|inlineStyleRanges|entityRanges|data|888934|在需要创建数据缓冲区时，即使大小是固定的，也可以使用std：：。|offset|length|style|BOLD|888935|在需要字符串时使用std::+string+。|888936|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性等？。|888937|向量:向量：：一个向量的用户总是可以找到它的大小，如果需要的话，可以调整矢量的大小。它甚至可以(通过(&(MyVector)符号)提供给can。当然，向量本身就会清理干净。|888938|std：：：几乎相同的原因是，它总是被正确初始化，它不能溢出，它将优雅地处理修改，比如连接、分配等等，并且以自然的方式(使用操作符而不是函数)|888939|entityMap^0|0|Q|5|0|9|D|0|0|1A|0|6|1|0|0|5|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@$D|W|E|X|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@$D|12|E|13|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@$D|15|E|16|F|G]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|Q|$]]

<h2>Use vector and string instead of C-style arrays and char *</h2>
Use std::vector whenever you need to create a buffer of data, even if the size is fixed.
Use std::string whenever you need to have a string.
How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?
std::vector: The user of a vector can always find its size, and the vector can be resized if needed. It can even be given (through the (&amp;(myVector[0])) notation) to a C API. Of course, the vector will clean after itself.
std::string: Almost the same reasons above.And the fact it will always be correctly initialized, that it can't be overrun, that it will handle modifications gracefully, like concatenations, assignation, etc, and in a natural way (using operators instead of functions)

blocks|key|253552|text|不要使用没有适当构造函数的结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253553|结构是合法的C%2B%2B结构，用于将数据聚合在一起。不过，应该始终正确初始化数据。|253554|所有C%2B%2B结构至少应该有一个默认构造函数，该构造函数将其聚合数据设置为默认值。|253555|struct+MyStruct+//+BAD
{
+++int+i+;+bool+j+;+char+*+k+;
}

struct+MyStruct+//+GOOD
{
+++MyStruct()+:+i(0),+j(true),+k(NULL)+:+{}

+++int+i+;+bool+j+;+char+*+k+;
}|code-block|syntax|javascript|253556|如果它们通常是以某种方式初始化的，则提供一个构造函数，使用户能够避免C样式的结构初始化：|253557|MyStruct+oMyStruct+=+{+25,+true,+"Hello"+}+;+//+BAD
MyStruct+oMyStruct(25,+true,+"Hello")+;++++++//+GOOD|253558|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性等？。|offset|length|style|BOLD|253559|由于struct没有适当的构造函数，因此该结构的用户将承担初始化该结构的任务。因此，以下代码将从一个函数复制到另一个函数：|253560|void+doSomething()
{
+++MyStruct+s+=+{+25,+true,+"Hello"+}+;
++//+Etc.
}

void+doSomethingElse()
{
+++MyStruct+s+=+{+25,+true,+"Hello"+}+;
++//+Etc.
}

//+Etc.|253561|这意味着，在C%2B%2B中，如果您需要在结构中添加一个字段，或者更改内部数据的顺序，您必须通过所有这些初始化来验证每个初始化是否正确。通过适当的构造函数，修改结构的内部结构与其使用分离。|253562|entityMap^0|0|0|0|0|0|0|0|1A|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|18|8|@$Q|19|R|1A|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|X|5|H|7|1C|8|@]|9|@]|A|$I|J]]|$1|Y|3|Z|5|6|7|1D|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

<h2>Never use structs without proper constructors</h2>
structs are legal C++ constructs, used to aggregate data together. Still, the data should be always properly initialized.
All C++ structs should have at least a default constructor, which will set its aggregated data to default values.
<pre><code>struct MyStruct // BAD
{
 int i ; bool j ; char * k ;
}

struct MyStruct // GOOD
{
 MyStruct() : i(0), j(true), k(NULL) : {}

 int i ; bool j ; char * k ;
}
</code></pre>
And if they are usually initialized in some way, provide a constructor to enable the user to avoid a C-style struct initialization:
<pre><code>MyStruct oMyStruct = { 25, true, &quot;Hello&quot; } ; // BAD
MyStruct oMyStruct(25, true, &quot;Hello&quot;) ; // GOOD
</code></pre>
How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?
Having struct without a proper constructor leaves the user of this struct the task of initializing it. So, the following code will be copy pasted from function to function:
<pre><code>void doSomething()
{
 MyStruct s = { 25, true, &quot;Hello&quot; } ;
 // Etc.
}

void doSomethingElse()
{
 MyStruct s = { 25, true, &quot;Hello&quot; } ;
 // Etc.
}

// Etc.
</code></pre>
Which means that, in C++, if you need to add a field in the struct, or change the order of the internal data, you have to go through all these initializations to verify each is still correct. With a proper constructor, modifying the internals of the structs is decoupled from its use.

blocks|key|893380|text|应该用一个点来解释值语义和实体语义之间的区别。它可以提供关于如何处理复制的典型代码片段，这是各种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893381|另见在C%2B%2B中编写副本构造器和赋值操作符的检查表|offset|length|893382|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/214891/checklist-for-writing-copy-constuctor-and-assignment-operator-in-c#214966^0|0|2|M|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

A point should be dedicated to explain the difference between value semantics and entity semantics. It could provide the typical code snippets about how copy is handled is the various cases.

See also <a href="https://stackoverflow.com/questions/214891/checklist-for-writing-copy-constuctor-and-assignment-operator-in-c#214966">Checklist for writing copy constuctor and assignment operator in C++</a>

blocks|key|253601|text|公共继承必须以Liskov替代原则(LSP)为模型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253602|当非常强的耦合有意义时，必须使用私有继承实现代码重用/导入，否则必须使用聚合实现。|253603|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Public inheritance must model The Liskov Substitution Principle (LSP).

Code reuse/import without substituability must be implemented with private inheritance when a very strong coupling makes sense, or with aggregation otherwise.

blocks|key|253631|text|不要向全局命名空间添加类型或函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253632|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Don't add types or functions to the global namespace.

blocks|key|1252683|text|小心C+API|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1252684|can可以非常高效，但需要公开的原始数据(即指针等)，这无助于代码的安全性。使用现有的C%2B%2B+API，或者用C%2B%2B代码封装C%2B%2B。|1252685|例如：|1252686|//+char+*+d,+*+s+;
strcpy(d,+s)+;+//+BAD

//+std::string+d,+s+;
d+=+s+;++++++++//+GOOD|code-block|syntax|javascript|1252687|不要使用strtok|1252688|斯特托克不是重入者。这意味着，如果一个strtok启动而另一个没有结束，一个将破坏另一个的“内部数据”。|1252689|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性等？。|offset|length|style|BOLD|1252690|使用can意味着使用原始类型，当sprintf走得太远(或者使用snprintf时会导致字符串裁剪，这是一种数据损坏)，这可能会导致缓冲区溢出(以及潜在的堆栈损坏)等有趣的bug。即使在处理原始数据时，malloc也很容易被滥用，如下代码所示：|1252691|int+*+i+=+(int+*)+malloc(25)+;+//+Now,+I+BELIEVE+I+have+an+array+of+25+ints!
int+*+j+=+new+int[25]+;++++++++//+Now,+I+KNOW+I+have+an+array+of+25+ints!|1252692|等。等等。|1252693|至于strtok:+C和C%2B%2B是支持堆栈的语言，使用户可以不关心堆栈上有哪些函数，以及在堆栈上调用哪些函数。斯特托克取消了“不关心”的自由。|1252694|entityMap^0|0|0|0|0|0|0|0|1A|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@$Q|1B|R|1C|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|H|7|1E|8|@]|9|@]|A|$I|J]]|$1|Y|3|Z|5|6|7|1F|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1G|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|13|$]]

<h2>Beware of C API</h2>

The C API can be very efficient, but will need exposed raw data (i.e. pointers, etc.), which won't help the safety of the code. Use existing C++ API instead, or encapsulate the C API with C++ code.

e.g.:

<pre><code>// char * d, * s ;
strcpy(d, s) ; // BAD

// std::string d, s ;
d = s ; // GOOD
</code></pre>

<h2>Never use strtok</h2>

strtok is not reentrant. Which means that if one strtok is started while another is not ended, one will corrupt the "internal data" of the other.

How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?

Using C API means using raw types, which can lead to interesting bugs like buffer overflow (and potential stack corruption) when a sprintf goes too far (or string cropping when using snprintf, which is a kind of data corruption). Even when working on raw data, malloc can be easily abused, as shown by the following code:

<pre><code>int * i = (int *) malloc(25) ; // Now, I BELIEVE I have an array of 25 ints!
int * j = new int[25] ; // Now, I KNOW I have an array of 25 ints!
</code></pre>

Etc. etc..

As for strtok: C and C++ are stack-enabled languages, that enable to user to not care about what functions are above his own on the stack, and what functions will be called below his own on the stack. strtok removes this freedom of "not caring"

blocks|key|889024|text|过早优化是万恶之源|type|unstyled|depth|inlineStyleRanges|entityRanges|data|889025|先写出安全正确的代码。|889026|然后，如果您有性能问题，如果您的分析器告诉您代码很慢，您可以尝试优化它。|889027|永远不要相信你会比编译器更好地优化代码片段。|889028|在寻找优化时，请研究所使用的算法，以及潜在的更好的备选方案。|889029|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性等？。|offset|length|style|BOLD|889030|通常，“优化”(或者说被认为是优化的)代码要清晰得多，并且倾向于通过原始的、靠近机器的方式来表达自己，而不是一种更面向业务的方式。有些优化依赖于开关，如果等，然后将更难测试，因为多个代码路径。|889031|当然，在分析之前的优化通常会导致零性能增益。|889032|entityMap^0|0|0|0|0|0|0|1A|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$L|11|M|12|N|O]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

<h2>Premature optimization is the root of all evil</h2>
Write safe and correct code first.
Then, if you have performance problems, and if your profiler told you the code is slow, you can try to optimize it.
Never believe you will optimize snippets of code better than the compiler.
When looking for optimizations, study the algorithms used, and potentially better alternatives.
How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?
Usually, &quot;optimized&quot; (or supposedly optimized) code is a lot less clearer, and tend to express itself through raw, near-the-machine way, instead of a more business-oriented way. Some optimizations rely of switchs, if, etc., and then will be more difficult to test because of multiple code paths.
And of course, optimization before profiling often lead to zero performance gain.

blocks|key|1252803|text|最好的标准是那些小的，紧紧地专注于什么才是真正重要的质量代码。他们不试图教授编码，也不试图强制一种特定的编码方式。它们通常坚持一致性特性和主观评审(例如，如果您团队的其他成员认为一段代码是可读的，符合一致性规则，并且会被注释，那么它将永远是好代码)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1252804|所以要重新强调:一致性-命名约定，空格管理，注释块，目录结构.其他什么都不重要|1252805|编辑达斯汀:标准的最大问题是例外。如果您的标准是“每行1条语句”，则无法编写以下虚构的示例：|1252806|SetColText(1,"col1");+SetColWidth(1,+10);
SetColText(2,"col1");+SetColWidth(2,+10);
...
SetColText(9,"col1");+SetColWidth(9,+10);|code-block|syntax|javascript|1252807|但我想说的是，这是更易读的，因此不容易出错，把它们分开。(我相信你能举出更好的例子)。|1252808|这就是我的观点--告诉人们如何编写代码，以及如何将其格式化为严格的规则--总是会以你没有预料到的方式和地点消失。所以，在执行了一些规则之后，相信你的编码者就能做到这一点要好得多。如果他们有一些规则要遵守，他们会写好的，有纪律的代码，这样你就不需要其他糟糕的规则了。|1252809|你会看到一些关于页面和页面的标准。(飞利浦C#+one有48页长！)|1252810|因此，考虑到您有一个高质量的编码团队，您需要做些什么才能更容易地使用他们的代码？答案总是一致的‘在哪里’他们把代码，而不是他们如何写它。例如：您总是有一个bin，并且项目中的obj目录是一个很好的标准。你可以拿起任何项目，知道事情在哪里。不像某个人在他的c:/mybin目录中构建他的所有二进制文件，因为这样对他来说更容易。|1252811|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

The best standards are those that are small and tightly focussed on what really matters to making quality code. They do not try to teach coding, they do not try to force a particular way of coding. They generally stick to consistency features and subjective reviews (eg, if the rest of your team think a piece of code is readable, fits with the consistency rules, and is commented, then its always going to be good code)

So to re-emphasise: consistency - naming convention, whitespace management, commenting blocks, directory structure. Nothing else really matters

Edit for Dustin:
the big problem with standards comes with the exceptions. If you have a standard that says "1 statement per line", you cannot write the following made-up example:

<pre><code>SetColText(1,"col1"); SetColWidth(1, 10);
SetColText(2,"col1"); SetColWidth(2, 10);
...
SetColText(9,"col1"); SetColWidth(9, 10);
</code></pre>

But I'd say that was more readable, and therefore less error-prone that splitting them up. (I'm sure you can come up with better examples).

This is my point - telling people how to write code, and how to format it to strict rules is always going to fall over in ways and places you didn't anticipate. So its far better to trust your coders to do it right after enforcing a few rules. If they have a few rules to follow, they will write good, disciplined code so you won't need the rest of the crappy rules.

You see some standards that go on for pages and pages. (The Philips C# one is 48 fecking pages long!)

So, given that you have a team of quality coders, what do you need to do to make it easier to work with their code? the answer is always consistency of 'where' they put the code, not how they write it. eg. you always have a bin, and obj directory in your project is a good standard. You can pick up any project and know where things are .. unlike someone building all his binaries in his c:/mybin directory because its easier for him.

blocks|key|1252840|text|知道谁是那个记忆的主人。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1252841|尽可能在堆栈上创建对象(没有无用的新对象)|unordered-list-item|1252842|除非真的需要，否则避免所有权的转移|1252843|使用RAII和智能指针|1252844|如果强制转换所有权(没有智能指针)，那么就清楚地记录代码(函数应该有一个明确的名称，始终使用相同的名称模式，如"char+*+allocateMyString()“和"void+deallocateMyString(char+*+p)”)。|1252845|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性等？。|offset|length|style|BOLD|1252846|没有清晰的内存所有权哲学会导致有趣的错误或内存泄漏，并且浪费时间，不知道这个函数返回的字符是否应该由用户释放，或者返回给一个特殊的去分配函数，等等。|1252847|尽可能地，分配内存的函数/对象必须是释放内存的函数/对象。|1252848|entityMap^0|0|0|0|0|0|0|1A|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|Y|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|11|8|@$M|12|N|13|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|14|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|15|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|V|$]]

<h2>Know who is owner of that memory.</h2>
<ul>
<li>create objects on stack as much as possible (no useless new)</li>
<li>Avoid transfer of ownership unless really needed</li>
<li>Use RAII and smart pointers</li>
<li>If transfer of ownership is mandated (without smart pointers), then, document clearly the code (the functions should have a non-ambiguous name, always using the same name pattern, like &quot;char * allocateMyString()&quot; and &quot;void deallocateMyString(char * p)&quot;.</li>
</ul>
How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?
Not having a clear memory ownership philosophy leads to interesting bugs or memory leaks, and time lost wondering if the char * returned by this function should be deallocated by the user, or not, or given back to a special deallocation function, etc..
As much as possible, the function/object allocating the memory must be the function/object deallocating it.

blocks|key|253787|text|限制您使用的类型|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253788|如果需要使用整数类型，请选择一个并保留它。这将避免与短、int、长等混合有关的问题。类型。|253789|//+BAD
int+i+;
long+j+;
short+k+;

//+GOOD+(if+you+choose+the+"int"+as+integer)
int+i+;
int+j+;
int+k+;|code-block|syntax|javascript|253790|实际类型也是如此:选择一种(例如双)，而不使用另一种。|253791|等。|253792|注意:仍然存在有符号/无符号的问题，这并不总是可以避免的，而且STL使用它自己的整数类型(即std::vector::size_type)，但是所有剩余的代码都不应该混合。|253793|注2:您可以使用type来“选择”有符号整数和实数的首选类型。如果需要的话，这将使低成本的改变成为可能。|253794|如何清楚地为更安全的代码提供便利，从而最大限度地减少出现神秘错误的风险，从而提高可维护性等？。|offset|length|style|BOLD|253795|一些bug是通过比较无符号类型和符号类型、神秘的精度损失或/溢出下的整数来创建的。|253796|编译器通常在编译时发送警告，但通常的答案是将警告“抛出”，这有助于隐藏错误。|253797|编辑|253798|plinth作了一个有用的评论，我会在这里复制粘贴：|253799|在编写了大量必须在硬件级别上与事物交互的代码之后，我不能对这个准则说太多话。对于这一级别的工作，我更喜欢将整体类型抽象为包含精度(即，int16、uint16、int32、uint32等)的名称-8月18日20:50|blockquote|253800|当然，plinth是对的。有时，您必须处理int16、uint8和其他“精确定义”类型。|253801|这并不会使上面的帖子失效，只需完成它。|253802|bug的来源是混合不同类型(例如，将无符号字符转换为int+)，因此必须避免这种混合。因此，适用下列规则：|253803|选择一个泛型整数类型(例如int)，并在处理泛型整数时坚持它(对于reals也可以这样说)。|unordered-list-item|253804|如果(而且只有当)您需要精确的类型(如uint8或int16)，请使用它们|253805|不要混合不同的类型。|253806|如果您的真的必须混合不同的类型，那么非常谨慎。|253807|下面是一个可能会中断的代码示例：|253808|void+*+doAllocate(uint32+i)
{
+++//+try+to+allocate+an+array+of+"i"+integers+and+returns+it
}

void+doSomething()
{
+++uint32+i0+=+225+;
+++int8+++i1+=+225+;++//+Oops...

+++doAllocate(i0)+;+++//+This+will+try+to+allocate+255+integers
+++doAllocate(i1)+;+++//+This+will+TRY+TO+allocate+4294967265
++++++++++++++++++++++//+integers,+NOT+225
}|253809|entityMap^0|0|0|0|0|0|0|0|0|1A|0|0|0|0|0|0|0|0|0|0|0|0|4|2|0|0|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1Z|8|@$S|20|T|21|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|22|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|23|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|24|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|25|8|@]|9|@]|A|$]]|$1|14|3|15|5|16|7|26|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|27|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|28|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|29|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|1F|7|2A|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|1F|7|2B|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|1F|7|2C|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|1F|7|2D|8|@$S|2E|T|2F|U|V]]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|F|7|2H|8|@]|9|@]|A|$G|H]]|$1|1Q|3|-4|5|6|7|2I|8|@]|9|@]|A|$]]]|1R|$]]

<h2>Limit the types you use</h2>
If you need to use an integer type, choose one and keep it. This will avoid the problems associated with mixing of short, int, long, etc.. types.
<pre><code>// BAD
int i ;
long j ;
short k ;

// GOOD (if you choose the &quot;int&quot; as integer)
int i ;
int j ;
int k ;
</code></pre>
The same goes for real types: Choose one (e.g. double), and do not use another.
Etc.
Note: There is still the issue of signed/unsigned, which can't always be avoided, and the fact STL use its own integer types (i.e. std::vector::size_type), but all the remaining code should not mixing.
Note 2: You could use typedef to &quot;choose&quot; your prefered type for signed integer and real numbers. This would enable a low-cost change if needed.
How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?
Some bugs are created by comparing unsigned type to signed types, mysterious loss of precision, or integer under/overflow.
Compilers usually send warnings at compile time, but then, the usually answer is to &quot;cast&quot; the warning away, which can help hide the error.
<h3>Edit</h3>
plinth made an useful comment I'll copy paste here:
<blockquote>
Having written a lot of code that has to interact with things at the hardware level, I can't say much for this guideline. For this level of work, I prefer the integral types to be abstracted to names that include the precision (ie, int16, uint16, int32, uint32, etc.) – plinth Aug 18 at 20:50
</blockquote>
plinth is right, of course. Sometimes you have to deal with int16, uint8 and other &quot;precisely defined&quot; types.
This does not invalidate the post above, only complete it.
The source of the bug is mixing different types (converting unsigned char into int, for example), thus, this kind of mixing must be avoided. The following rules thus apply:
<ul>
<li>Choose one generic integral type (e.g. int), and stick to it when dealing with generic integers (the same can be said about reals)</li>
<li>If (and only if) you need exact types (like uint8 or int16), use them</li>
<li>Never mix different types.</li>
<li>If you really must mix different types, then be very very cautious.</li>
</ul>
Below is an example of code that would break:
<pre><code>void * doAllocate(uint32 i)
{
 // try to allocate an array of &quot;i&quot; integers and returns it
}

void doSomething()
{
 uint32 i0 = 225 ;
 int8 i1 = 225 ; // Oops...

 doAllocate(i0) ; // This will try to allocate 255 integers
 doAllocate(i1) ; // This will TRY TO allocate 4294967265
 // integers, NOT 225
}
</code></pre>

blocks|key|1252985|text|最小惊奇原则。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1252986|也许这不是你想要的规则的“味道”，但我肯定会把它放在第一位。|1252987|它不仅是对所有无聊的东西(如格式化和注释指导方针)的根源、理性和理智的检查，而且对我来说--更重要的是--强调正在阅读和理解的代码，而不是仅仅编译代码。|1252988|它还涵盖了我所遇到的唯一合理的代码质量度量--+WTF每分钟。|1252989|我首先要强调清楚、一致的代码的重要性和价值，并在编码标准中激发以下内容。|1252990|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Principle_of_least_astonishment|1|http://www.osnews.com/story/19266/WTFs_m^0|0|6|0|0|0|0|O|6|1|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|O|P|Q|C|$R|U]]]]

<a href="http://en.wikipedia.org/wiki/Principle_of_least_astonishment" rel="nofollow noreferrer">Principle of least surprise</a>.

Maybe it's not the "flavor" of rules you are looking for, but I'd definitely put it first. 

It is not only the root, reason and sanity check for all the boring stuff like formatting and commenting guidelines, but - to me more importantly - puts the emphasis on the code being read and understood, rather than just compiled. 

It also covers the only reasonable code quality measure I have ever encountered - <a href="http://www.osnews.com/story/19266/WTFs_m" rel="nofollow noreferrer">WTF's per minute</a>. 

I'd use that first point to stress the importance and value of clear, consistent code, and to motivate the following items in the coding standard.

blocks|key|253916|text|更喜欢符合标准的代码。更喜欢使用标准库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|253917|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Prefer standard-compliant code. Prefer to use the standard libraries.

blocks|key|1253041|text|我认为编码标准文档并不能解决这个问题。解决办法是激励你的劳动去学习/关心编码的人类方面--“人类第一，计算机是最后的代码”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1253042|显然，不可能仅仅解雇那些不关心的人--但标准文档也不会对他们有多大帮助。|1253043|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think a coding standard document isn't the solution to this problem. The solution is to motivate your labor to learn/care about the human side of coding - "code for people first and computers last".

Obviously it is not possible to just fire the ones that don't care - but a standard document isn't going to help them much, either.

blocks|key|1253045|text|我建议只要求开发人员阅读一堆指南，以及Meyers的有效C%2B%2B和更有效的C%2B%2B书籍。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1253046|如果您想要轻量级，您将不得不依靠常识和共同的理想。|1253047|代码评审也有助于执行此操作。|1253048|为了保持轻量级，我将避免文档和代码警察。公开赞扬好代码。|1253049|编辑-我从这里的评论开始，但为了便于查看，我会把它放在响应中：|1253050|正确完成评审将产生奇迹--但是您不能允许在评审中报告层次结构，并且不能在评审结果中显示人名的统计数据。|1253051|确保文档保持较小，并确保给出“规则”/guideline的理由。否则，你只会要求盲目的服从。有了你的理由和理由，你才能真正地发布/写“规则”成为不必要的。(因为这一概念将被内化)|1253052|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I suggest just requiring developers to read a bunch of guidelines, and the effective C++ and more effective C++ books by Meyers. 

If you want lightweight, you are going to have to rely on common sense and a common ideal. 

Code reviews help enforce this as well.

To keep it lightweight I would avoid a document and code police. Praise good code publicly.

EDIT - I started with a comment here, but will put it in the response for ease of viewing:

reviews done correctly will do wonders - but you can't allow reporting hierarchies into the review and no statistics with people's names can be on the review results. 

Make sure to keep the document small and be sure to give REASONS for the "rule"/guideline. Without that then you ae just demanding blind obedience. With rationale and reasons you educate so that actually posting/writing the "rule" becomes unneeded. (as the concept will be internalized)

blocks|key|893588|text|总是，总是，总是在对象构造上进行正确的数据成员初始化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893589|我遇到了一个问题，一个对象构造函数依赖于它的数据成员的某些“默认”初始化。在两个平台(Windows/Linux)下构建代码会产生不同的结果和难以找到的内存错误。结果是，数据成员没有在构造函数中初始化，而是在初始化之前使用。在一个平台(Linux)上，编译器将其初始化为代码编写者认为合适的默认值。在Windows上，值被初始化为某种东西--但是是垃圾。在使用数据成员时，一切都乱了套了。一旦初始化被修复-没有更多的问题。|893590|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Always, always, always do proper data member initialization on object construction.

I ran into a problem where an object constructor was relying on some "default" initialization for its data members. Building the code under two platforms (Windows/Linux) gave different results and a hard-to-find memory bug. The result was that a data member was not initialized in the constructor, and used before it was initialized. On one platform (Linux), the compiler initialized it to what the code writer thought appropriate default. On Windows, the value was initialized to something - but garbage. On use of the data member, everything went haywire. Once the initialization was fixed - no more problem.

blocks|key|1253120|text|也许是一个不需要思考的人，但也是一条重要的规则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1253121|避免未定义的行为。|1253122|在C%2B%2B中有很多，编写一个不依赖于它的非平凡应用程序可能是不可能的，但是一般的规则仍然应该是“未定义的行为是不好的”。(因为遗憾的是，有一些C%2B%2B程序员认为“它在我的机器/编译器上工作”已经足够好了)。|1253123|如果你必须依赖它，告诉每个人什么，为什么，地点和方式。|1253124|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Probably a no-brainer, but nevertheless an important rule:

Avoid undefined behavior.

There's an awful lot of it in C++, and it's probably impossible to write a nontrivial application that doesn't depend on it somehow, but the general rule should still be "undefined behavior is bad". (Because sadly there are C++ programmers out there who feels that "it works on my machine/compiler" is good enough).

If you have to rely on it, make it clear to everyone what, why, where and how.

blocks|key|893601|text|确保析构函数定义为虚拟|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|893602|+class+GoodClass+{
+public:
+++GoodClass();
+++virtual+~GoodClass()
+};

+class+BadClass+{
+public:
+++BadClass();
+++~BadClass()
+};|code-block|syntax|javascript|893603|entityMap^0|9|2|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

Make sure destructors are defined as virtual:

<pre><code> class GoodClass {
 public:
 GoodClass();
 virtual ~GoodClass()
 };

 class BadClass {
 public:
 BadClass();
 ~BadClass()
 };
</code></pre>

blocks|key|1253170|text|计算机编程艺术[1，2，3]|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1253171|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The Art of Computer Programming Tome{1,2,3}

blocks|key|1253189|text|通过const引用传递输入参数，并通过指针传递输出或输入-输出参数.这是一条与谷歌风格指南相仿的规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1253190|我过去对指针有一种绝对的厌恶，我喜欢尽可能地使用引用(正如这个帖子中的一张海报所建议的)。然而，采用这种输出-arg指针约定使我的函数更具可读性。例如,|1253191|SolveLinearSystem(left_hand_side,+right_hand_side,+&params);|code-block|syntax|javascript|1253192|清楚地表明"params“正在被写到。|1253193|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Pass input arguments by const reference, and output or input-output arguments by pointer. This is a rule borrwed from the Google style guide. 

I used to have an absolute aversion to pointers and preferred to use references whenever possible (as suggested by one of the posters in this thread). However, adopting this output-arg-as-pointer convention has made my functions much more readable. For example, 

<pre><code>SolveLinearSystem(left_hand_side, right_hand_side, &amp;params);
</code></pre>

makes it clear that "params" is being written to.

blocks|key|893647|text|将您的编码样式建立在"C%2B%2B编码标准“(Sutter/Alexandrescu)的基础上，并且只记录您偏离它的地方。我不能认真对待任何"C%2B%2B编码标准“。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|893648|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Base your coding style off of "C++ Coding Standard" (Sutter/Alexandrescu), and only document where you deviate from it. I cannot take any "C++ Coding Standard" serious that doesn't.

blocks|key|254182|text|规则0应该始终是：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|254183|记录与此标准的任何偏差|254184|有些问题可能导致不遵守某一特定标准.|254185|这些情况下，必须对进行记录和证明，因为它们表示偏离了代码库中的预期成语。|254186|不记录它们可能会导致错误，因为：|254187|未来的维护人员可能会使代码遵从，而不理解为什么它一开始就不兼容。|ordered-list-item|254188|未来的开发人员可能期望代码符合，因此对其含义做出错误的假设。|254189|entityMap^0|0|9|0|0|6|0|0|6|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|10|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|14|8|@]|D|@]|E|$]]|$1|N|3|O|5|P|7|15|8|@]|D|@]|E|$]]|$1|Q|3|R|5|P|7|16|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|T|$]]

Rule 0 should always be:

<h2>Document any deviations from this standard</h2>

Some problems may necessitate non-adherence to a particular standard.

These cases must be documented and justified because they indicate a deviation from the expected idioms in the codebase.

Not documenting them can cause bugs because:

<ol>
<li>A future maintainer may bring the code to compliance without
understanding why it was non-compliant in the first place.</li>
<li>A future developer may expect the code to conform and so make
incorrect assumptions about its meaning.</li>
</ol>

I've been involved in developing coding standards which were quite elaborate. My own experience is that it was hard to enforce if you don't have proper processes to maintain it and strategies to uphold it.

Now I'm working in, and leading, an environment even less probable to have processes and follow-up strategies in quite a while. Still I want to uphold some minimum level of respectable code. So I thought I would get good suggestions here, and we might together produce a reasonable light-weight subset of the most important coding standard practices for others to use as reference.

So, to emphasize the essence here:

<h2> What elements of a C++ coding standard are the most crucial to uphold?</h2>

<ul>
<li><h2>Answering/voting rules</h2>

<ul>
<li>1 candidate per answer, preferably with a brief motivation.</li>
<li>Vote down candidates which focuses on style and subjective formatting guidelines. This is not to indicate them as unimportant, only that they are less relevant in this context. </li>
<li>Vote down candidates focusing on how to comment/document code. This is a larger subject which might even deserve its own post.</li>
<li>Vote up candidates that clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.</li>
<li>Don't cast your vote in any direction on candidates you are uncertain about. Even if they sound reasonable and smart, or on the contrary "something surely nobody would use", your vote should be based on clear understanding and experience.</li>
</ul></li>
</ul>

Most crucial elements in a light-weight C++ coding standard

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我参与了编码标准的开发，这些标准非常详细。我自己的经验是，如果没有适当的过程来维护它和维护它的策略，就很难执行它。现在，我正在工作，并领导着一个环境，在相当长的一段时间内，更不可能有流程和后续策略。不过，我还是想维护一些最低标准的可敬代码。因此，我想我会在这里得到好的建议，我们可以一起产生一个合理的轻量级子集，这是最重...

问轻量级C++编码标准中最关键的元素
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问轻量级C++编码标准中最关键的元素EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问轻量级C++编码标准中最关键的元素
EN