我已经阅读了有关缩进样式的Wikipedia文章,但我仍然不明白。K&R和1TBS有什么区别?
我已经阅读了有关缩进样式的Wikipedia文章,但我仍然不明白。K&R和1TBS有什么区别?
Answers:
K&R是这样的:
if (x)
a();
else {
b();
c();
}
也就是说:大括号仅在需要的地方使用,在与控制语句相同的行上打开大括号,在自己的行上关闭大括号。
“一个真正的花括号样式”(1TBS或OTBS)通过将一个受控语句括在花括号中而将其变成复合语句:
if (x) {
a();
} else {
b();
c();
}
Allman样式比1TBS稍远一些,并且通过将开口撑杆本身也放置在一条线上来强制垂直间距:
if (x)
{
a();
}
else
{
b();
c();
}
编辑:
我仍在尝试确切地说出“丹尼斯·里奇(Dennis Ritchie)是一个非常聪明的人,他不仅发明了一种好的语言,而且还发明了一种非常好的支撑风格”,这完全符合“傲慢”的意思。
对于那些坚持认为它仍然是自大的人来说,这是一个小挑战:前往Sourceforge,Github等),并使用K&R花括号样式挑选项目。通过他们的错误和犯的记录去,并试图找到一个单一的,是由他们使用支具风格造成的错误。
如果您不想做那么多工作,请尝试进行简单的统计分析。比较使用不同花括号样式的项目,并查看是否可以显示“双峰”(bimodality),这是与括号样式相关的错误计数(严重性等)的统计上显着差异。
几年前,我都做过这两种事情,但是找不到一个可以归因于支撑样式的错误,也找不到任何在两者之间具有统计学上显着相关性的东西。平均而言,那些使用K&R支撑有小幅更少的错误,但差异太大太小,有资格作为统计显著。
自从它被提出以来,我将使用多语句宏评论这种情况。包含多个语句但不使用大括号括起来的宏存在一个错误。我的工作不是编写掩盖该错误的代码。恰恰相反,我的工作是尽快找到并消除该错误。
编写代码以期掩盖错误,以使它们无法得到诊断和修复,这是彻头彻尾的邪恶。如果愿意,可以称呼那个傲慢的人,但我认为这几乎没有商量的余地。应该找到并修复错误,而不要掩盖。存在的时间越长,修复它们的可能性就越大,难度也就越大。
通常,KR大括号样式的问题在于代码重构。在四处移动代码时,很容易会漏掉一些括号,错误地移动它(或移动它下面的东西,以为它是有条件执行的),然后在某些东西不再起作用时挠头,或者不幸地陷入困境。一个未经良好测试的代码区域,直到黑帽找到利用它的方法,该错误才被注意到。如果您发现问题,则快速进入调试器很容易找到问题,但是如果没有发现...