我在读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++;
使用第一个版本的好处是什么?
我能想到的最贴切的例子是:
if(someCondition)
if(someOtherCondition)
DoSomething();
else
DoSomethingElse();
Which if will the else be paired with? Indentation implies that the outer if gets the else, but that's not actually how the compiler will see it; the inner if will get the else, and the outer if doesn't. You would have to know that (or see it behave that way in debugging mode) to figure out by inspection why this code might be failing your expectations. It gets more confusing if you know Python; in that case you know that indentation defines code blocks, so you would expect it to evaluate according to the indentation. C#, however, doesn't give a flying flip about whitespace.
话虽如此,从表面上看,我并不特别同意这个“总是使用括号”的规则。它使代码的垂直噪声非常大,降低了快速读取代码的能力。如果语句是:
if(someCondition)
DoSomething();
... then it should be written just like this. The statement "always use brackets" sounds like "always surround mathematical operations with parentheses". That would turn the very simple statement a * b + c / d into ((a * b) + (c / d)), introducing the possibility of missing a close-paren (the bane of many a coder), and for what? The order of operations is well-known and well-enforced, so the parentheses are redundant. You'd only use parentheses to enforce a different order of operations than would normally be applied: a * (b+c) / d for instance. Block braces are similar; use them to define what you want to do in cases where it differs from the default, and is not "obvious" (subjective, but usually pretty common-sense).
我对这位讲师的能力表示怀疑。考虑到他
点:
OK
Would anyone really write (or want to read) (b*b) - ((4*a)*c)?
Some precedences are obvious (or should be), and the extra parentheses
just add to confusion. (On the other hand, you _should_ use the
parentheses in less obvious cases, even if you know that they're not
needed.)
Sort of. There are two wide spread conventions for formatting
conditionals and loops:
if ( cond ) {
code;
}
and:
if ( cond )
{
code;
}
In the first, I'd agree with him. The opening { is not that visible,
so it's best to assume it's always there. In the second, however, I
(and most of the people I've worked with) have no problem with omitting
the braces for a single statement. (Provided, of course, that the
indentation is systematic and that you use this style consistently.
(And a lot of very good programmers, writing very readable code, omit
the braces even when formatting the first way.)
NO. Things like if ( NULL == ptr ) are ugly enough to hinder
readability. Write the comparisons intuitively. (Which in many cases
results in the constant on the right.) His 4 is bad advice; anything
which makes the code unnatural makes it less readable.
NO. Anything but int is reserved for special cases. To
experienced C and C++ programmers, the use of unsigned signals bit
operators. C++ doesn't have a real cardinal type (or any other
effective subrange type); unsigned doesn't work for numeric values,
because of the promotion rules. Numerical values on which no
arithmetic operations would make sense, like serial numbers, could
presumably be unsigned. I'd argue against it, however, because it
sends the wrong message: bitwise operations don't make sense either.
The basic rule is that integral types are int, _unless_ there is a
significant reason for using another type.
NO. Doing this systematically is misleading, and doesn't actually
protect against anything. In strict OO code, delete this; is often
the most frequent case (and you can't set this to NULL), and
otherwise, most delete are in destructors, so you can't access the
pointer later anyway. And setting it to NULL doesn't do anything
about any other pointers floating around. Setting the pointer
systematically to NULL gives a false sense of security, and doesn't
really buy you anything.
查看任何典型参考文献中的代码。Stroustrup违反
除了第一条,你给出的每一条规则。
我建议你换个讲师。一个真正知道什么的人
他说的是。
当你完成它时,最好将指针设置为NULL。
下面是一个例子:
A类行为如下:
分配一块内存
然后一段时间后,它删除这块内存,但不将指针设置为NULL
B类做以下事情
分配内存(在这个实例中,它得到的内存块恰好与类a删除的内存块相同)
在这一点上,类A和类B都有指向同一个内存块的指针,就类A而言,这块内存块不存在,因为它已经用完了。
考虑以下问题:
如果在类a中有一个逻辑错误,导致它写入现在属于类B的内存呢?
在这个特定的实例中,您不会得到一个糟糕的访问异常错误,因为内存地址是合法的,而类A现在有效地破坏了类B数据。
类B可能最终崩溃,如果它遇到意外值,当它崩溃时,很有可能,当问题出现在类a时,您将花费相当长的时间在类B中查找这个bug。
如果您已经将删除的内存指针设置为NULL,那么只要类A中的任何逻辑错误试图写入NULL指针,您就会得到一个异常错误。
如果您担心在指针第二次为NULL时使用双重删除会出现逻辑错误,那么可以为此添加assert。