我正在阅读一些C ++讲师的讲义，他写了以下内容：
- 使用缩进 // 好的
- 永远不要依赖于运算符优先级 - 始终使用括号 // 好的
- 即使只有一行也要使用 { } 块 // 不好，为什么？
- 比较中将 const 对象放在左侧 // 好的
- 对于变量大于或等于0，请使用unsigned // 很好的技巧
- 在删除后将指针设置为NULL - 双重删除保护 // 还不错
第三种技术对我来说不太清楚：将一行代码放在{ ... }中会给我带来什么好处？
例如，看这个奇怪的代码：
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
if (i % 2 == 0)
{
j++;
}
}
并将其替换为：
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
if (i % 2 == 0)
j++;
使用第一版本的好处是什么？
让我们尝试在增加j时也修改i：
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
if (i % 2 == 0)
j++;
i++;
哦，不好了！从Python的角度来看，这似乎是可以的，但实际上并不是，因为它相当于：
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
if (i % 2 == 0)
j++;
i++;
当然，这是一个愚蠢的错误，但即使是有经验的程序员也可能犯这种错误。
另一个非常好的原因在ta.speot.is's answer中指出。
第三个我能想到的原因是嵌套的if语句：
if (cond1)
if (cond2)
doSomething();
现在假设你想要在cond1未达到时执行doSomethingElse()(新功能)。那么：
if (cond1)
if (cond2)
doSomething();
else
doSomethingElse();
很明显这是错误的，因为else与内部的if相关联。
编辑：由于这引起了一些关注，我将澄清我的观点。我回答的问题是：
使用第一个版本有什么好处？
我已经描述了一些好处，但在我看来，“总是”规则并不总是适用。所以我不完全支持
始终使用{ }块——即使只有一行//不行的原因是什么？
我并不是说总是使用{}块。如果它是一个足够简单的条件和行为，就不需要使用。如果你怀疑有人后来会更改你的代码以添加功能，请使用{}块。
j++ 之前加上 i++，那么这两个变量在使用时仍然在作用域内。 - Mike Seymouri++; 不是循环部分的方式进行缩进。(在过去，这可能是一个合理的论点，我曾经遇到过这样的问题。大约20年前。从那以后就没有了。) - James Kanze如果您不使用大括号{和}，很容易在注释中意外改变控制流程。例如：
if (condition)
do_something();
else
do_something_else();
must_always_do_this();
do_something_else()注释掉，你会得到这样的结果：if (condition)
do_something();
else
//do_something_else();
must_always_do_this();
代码可以编译，但并非总是调用 must_always_do_this()。
我们在代码库中遇到过这个问题，有人在发布之前迅速禁用了某些功能。幸运的是，我们在代码审查中发现了这个问题。
must_always_do_this();会被执行，这是一种规定行为。 - Mr.Anubisif(debug) \n //print(info);。基本上把整个库都删掉了。 - Kevinint，除非有明显的原因使用其他类型。
delete this;经常是最常见的情况（您不能将this设置为NULL），否则，大多数delete都在析构函数中，所以您无法访问指针。稍后无论如何，将其设置为NULL并不能解决浮动的任何其他指针问题。将指针系统地设置为NULL会给人一种虚假的安全感，并且实际上并不能为您带来任何好处。
查看任何典型参考资料中的代码。例如，Stroustrup违反了您给出的每条规则，除了第一条。
我建议您找另一个讲师。 找一个真正知道自己在说什么的人。
delete this，它比我所看到的更常见吗？我认为将指针设置为NULL以后并没有什么坏处，但因人而异。也许只是我的感觉，但他的大多数建议似乎并不那么糟糕。 - Firedragonif (ptr = NULL)发出警告，除非你将其写成if ((ptr = NULL))。我同意James Kanze的观点，将NULL放在首位很难看，因此我坚决反对这种写法。 - Leounsigned 则表示程序员有一个愿望，即该变量应该只表示正数。将其与有符号数混合使用通常会引起编译器警告，这可能是讲师的本意。 - Component 10size_t类型呢？ - ta.speot.is考虑一个函数，在开头有很多警卫条款（是的，在其他语言中，以下代码是糟糕的C++代码，但这种情况相当普遍）：
void some_method(obj* a, obj* b)
{
if (a == nullptr)
{
throw null_ptr_error("a");
}
if (b == nullptr)
{
throw null_ptr_error("b");
}
if (a == b)
{
throw logic_error("Cannot do method on identical objects");
}
if (not a->precondition_met())
{
throw logic_error("Precondition for a not met");
}
a->do_something_with(b);
}
void some_method(obj* a, obj* b)
{
if (a == nullptr)
throw null_ptr_error("a");
if (b == nullptr)
throw null_ptr_error("b");
if (a == b)
throw logic_error("Cannot do method on identical objects");
if (not a->precondition_met())
throw logic_error("Precondition for a not met");
a->do_something_with(b);
}
matrix operator +(matrix const& a, matrix const& b) {
matrix c(a.w(), a.h());
for (auto i = 0; i < a.w(); ++i)
for (auto j = 0; j < a.h(); ++j)
c(i, j) = a(i, j) + b(i, j);
return c;
}
与之比较：
matrix operator +(matrix const& a, matrix const& b) {
matrix c(a.w(), a.h());
for (auto i = 0; i < a.w(); ++i)
{
for (auto j = 0; j < a.h(); ++j)
{
c(i, j) = a(i, j) + b(i, j);
}
}
return c;
}
自从我最初写下这个答案以来，我大多数时间都接受了普遍的代码风格，并使用花括号，除非我可以将整个单语句放在前一行。我仍然认为不使用冗余的花括号通常更易读，并且我仍然从未遇到由此引起的错误。
if (a == nullptr) { throw null_ptr_error("a"); }写成一行。 - Steve Jessop我所工作的代码库中，有些人过分厌恶大括号，这让后来的人来维护这个代码库时会感到困难。
我遇到的最常见的问题是这样的：
if (really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
this_looks_like_a_then-statement_but_isn't;
如果我不小心添加一个 then 语句，代码可能会变成这样：
if (really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
this_looks_like_a_then-statement_but_isn't;
i_want_this_to_be_a_then-statement_but_it's_not;
}
考虑到添加大括号只需要约1秒钟，并且可以节省您至少几分钟的混淆调试时间，为什么您不选择减少歧义的选项？对我来说，这似乎是虚假经济。
if(really long...editor){ do_foo;}）会如何帮助你避免这种情况？看起来问题仍然是一样的。个人而言，我倾向于在不必要的情况下避免使用大括号，但这与编写大括号所需的时间无关，而是由于代码中增加了两行降低了可读性。 - Grizzly我的建议:
使用缩进
显然。
永远不要依赖运算符优先级-始终使用括号
我不会使用“永远”和“始终”这些词，但通常情况下，我认为这个规则很有用。在某些语言（如Lisp、Smalltalk）中，这不是一个问题。
即使只有一行代码也要使用{ }代码块
我从来没有这样做过，也从来没有遇到过任何问题，但我可以看出这对学生可能很有好处，特别是如果他们之前学过Python。
比较时，将const对象放在左侧
尤达条件？不，谢谢。它会影响可读性。只需在编译代码时使用最高警告级别。
对于值大于等于0的变量，请使用无符号类型
好的。有趣的是，我听说Stroustrup并不赞同。
在删除后将指针设置为NULL-双重删除保护
不好的建议！永远不要有一个指向已删除或不存在对象的指针。
unsigned存在问题”的说法，其中一个问题是当C++比较大小相似的有符号和无符号类型时，在进行比较之前会将其转换为无符号类型，这导致数值发生变化。转换为有符号类型并不一定更好；实际上应该将比较看作是“仿佛”将两个值转换为能够表示任一类型中所有值的较大类型进行比较。 - James Kanzeexp（double）返回一个超过MAX_INT的值有任何问题:-)。但再次，真正的问题是隐式转换。 int i = exp（1e6）;是完全有效的C ++。 Stroustrup实际上曾经提议废弃有损隐式转换，但委员会并不感兴趣。（一个有趣的问题：unsigned->int是否被认为是有损的。我认为unsigned->int和int->unsigned都是有损的。这将大大使unsigned可以接受。 - James Kanze它更加直观易懂，使意图清晰。
并确保在新用户无意中遗漏添加新的代码语句时，代码不会出现错误，因为使用它可以保证代码的完整性。
除了之前的回答中提出的非常明智的建议，我想补充一个例子，说明这个问题为什么很关键。在重构一些代码时，我遇到一个例子，需要将一个非常大的代码库从一个 API 切换到另一个 API。第一个 API 有一个设置公司 ID 的调用，如下所示：
setCompIds( const std::string& compId, const std::string& compSubId );
相比之下，替换需要两个调用：
setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );
我使用正则表达式进行更改，这非常成功。我们还通过astyle对代码进行了修改，使其更易读。但在审核过程中，我发现在某些条件下会发生以下更改：
if ( condition )
setCompIds( compId, compSubId );
翻译为：
变成这样：
if ( condition )
setCompId( compId );
setCompSubId( compSubId );
这显然不是所需的结果。我不得不回到一开始，将替换视为完全在一个块内，并手动修改任何看起来有问题的地方（至少它不会是不正确的）。
我注意到astyle现在有一个选项--add-brackets，可以在没有括号的情况下添加括号，如果你发现自己处于与我相同的位置，我强烈推荐使用此选项。
#define FOO() func1(); \ func2();，同样适用于搜索和替换。话虽如此，我曾见过“始终使用大括号”被提升为一种风格规则，正是因为它可以让你避免将所有多语句宏包装在do...while(0)中。但我持不同意见。 - Steve Jessopinline之前我们确实需要），那么你应该尽可能让它们像函数一样工作，必要时使用do { ... } while(0)技巧（以及大量额外的括号）。但如果这是公司的风格，仍然无法阻止你到处使用大括号。（值得一提的是：我曾在各种不同的公司工作过，涵盖了所有在此讨论的风格。我从未发现任何一个严重的问题。） - James Kanze我在所有地方都使用 {} ，除了一些明显的情况。单行代码就是其中之一：
if(condition) return; // OK
if(condition) //
return; // and this is not a one-liner
当你在返回语句之前添加某些方法时，这可能会对你造成影响。缩进表示当条件满足时，返回语句正在执行，但它始终会返回。
C#中另一个例子是使用语句。
using (D d = new D()) // OK
using (C c = new C(d))
{
c.UseLimitedResource();
}
这相当于
using (D d = new D())
{
using (C c = new C(d))
{
c.UseLimitedResource();
}
}
using缺乏自动缩进）。 - Konrad RudolphThe most pertinent example I can think of:
if(someCondition)
if(someOtherCondition)
DoSomething();
else
DoSomethingElse();
if与else配对？缩进暗示外部的if会得到else，但编译器实际上不���这样看待它的；内部if将得到else，而外部if不会得到。你必须知道这一点（或在调试模式下看到它以这种方式运行），才能通过检查弄清楚为什么该代码可能未达预期。如果你了解Python，则会更加困惑；在这种情况下，你会知道缩进定义了代码块，因此你会根据缩进来评估代码。然而，在C#中，空格并不起任何作用。if(someCondition)
DoSomething();
如果语句 "总是使用括号" 被写成像这样。它听起来像是 "总是用括号包围数学运算"。这将把非常简单的语句 a * b + c / d 变成 ((a * b) + (c / d))，引入了错失闭合括号（许多码农的噩梦）的可能性，而这样做的目的是什么呢？操作顺序是众所周知且被严格执行的，因此括号是多余的。只有在需要强制执行与通常应用的不同操作顺序时，才会使用括号：例如 a * (b+c) / d。块级花括号也是如此；在需要定义与默认情况不同且不 "显而易见"（主观的，但通常很常识性）的内容时，请使用它们。
else与第一个if配对，而不是第二个。请取消您的反对票。 - KeithS
for (unsigned i = 100; i >= 0; --i)。 - Archie(i % 2 == 0)与(2)相矛盾。你在依赖运算符优先级，当然意思应该是((i % 2) == 0)而不是(i % (2 == 0))。我会将规则2分类为“有效的观点，但‘总是’是错误的”。 - Steve Jessop