我在读c++老师的课堂笔记,他是这样写的:
使用缩进// OK
永远不要依赖运算符优先级-总是使用括号// OK
总是使用{}块-即使是单行//不可以,为什么??
Const对象在比较的左边// OK
对>= 0的变量使用unsigned,这是个不错的技巧
删除后将指针设置为NULL -双重删除保护//不错
第三种方法我不清楚:放一行进去能得到什么
A{…} ?
例如,下面这段奇怪的代码:
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++;
使用第一个版本的好处是什么?
我的2 c:
使用缩进
很明显
永远不要依赖运算符优先级——总是使用括号
我不会使用“从不”和“总是”这样的词,但总的来说,我认为这条规则是有用的。在某些语言(Lisp, Smalltalk)中,这不是问题。
总是使用{}块-即使是单行
我从来没有这样做过,也从来没有遇到过任何问题,但我可以看到它对学生有什么好处,特别是如果他们以前学过Python的话。
Const对象在比较的左边
尤达条件?不,请。它损害了可读性。在编译代码时使用最大警告级别即可。
对于>= 0的变量使用unsigned
好的。有趣的是,我听到斯特劳斯特鲁普不同意。
删除后将指针设置为NULL -双重删除保护
坏的建议!永远不要使用指向已删除或不存在的对象的指针。
在“总是使用牙套”的营地呆了10年之后,我最近开始不怎么使用牙套了。
主要是受到Bob叔叔关于如何编写干净代码的争论的启发,我现在相信不使用大括号编写代码更具有可读性。
if(guardClause)
throw new SomeException(..)
Bob大叔认为,在if/for语句中编写多行代码是潜在的可读性问题。
e.g.
if(someCondition)
{
doTechnicalThingX();
doTechnicalThingY();
doTechnicalThingZ();
}
应该被重构为
if(someCondition)
doFunctionalThingA();
对我来说,不把大括号放在那里是有帮助的,因为我得到提醒,我在if块中写了太多代码。
正如其他人所提到的,我相信代码风格是团队决策。
如果不使用{和},很容易意外地用注释更改控制流。例如:
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()并不总是被调用。
我们在代码库中遇到了这个问题,有人在发布之前很快地禁用了一些功能。幸运的是,我们在代码审查中发现了它。
我的2 c:
使用缩进
很明显
永远不要依赖运算符优先级——总是使用括号
我不会使用“从不”和“总是”这样的词,但总的来说,我认为这条规则是有用的。在某些语言(Lisp, Smalltalk)中,这不是问题。
总是使用{}块-即使是单行
我从来没有这样做过,也从来没有遇到过任何问题,但我可以看到它对学生有什么好处,特别是如果他们以前学过Python的话。
Const对象在比较的左边
尤达条件?不,请。它损害了可读性。在编译代码时使用最大警告级别即可。
对于>= 0的变量使用unsigned
好的。有趣的是,我听到斯特劳斯特鲁普不同意。
删除后将指针设置为NULL -双重删除保护
坏的建议!永远不要使用指向已删除或不存在的对象的指针。