嗨,我有一个简单的问题,我已经问了3-4个不同的人,他们每个人都有不同的答案。
哪种代码布局更好,使用更多?
只要它一致,它真的很重要吗?在作为程序员工作的世界中,这被视为更好的实践?
例如
A)
for(int i=0;i<8;i++)
{
for(int p=0;p<8;p++)
{
if(array[i][p]->Equals(String))
{
//Do Stuff
}
}
}
OR
B)
for(int i=0;i<8;i++){
for(int p=0;p<8;p++){
if(array[i][p]->Equals(String)){
//Do Stuff
}
}
}
谢谢, 添
答案 0 :(得分:1)
存在多种已发布的样式指南 - 例如,Google的here,并强制执行以下功能:
ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
DoSomething();
...
}
和阻止:
if (condition) { // no spaces inside parentheses
... // 2 space indent.
} else { // The else goes on the same line as the closing brace.
...
}
其他块的类似示例。
所以,看看几个这样的风格指南,选择一个来自一个有点声望的来源和你喜欢的,如果有人反对你的风格只是说“哦,我从X拿起它”(其中X可能是Google,geosoft或您喜欢的其他任何来源(列出here以上的更多内容)。
答案 1 :(得分:1)
在实践中几乎所有情况下,都有一个明确的答案:使用您正在使用的代码库中当前使用的样式。如果您要开始一个新项目,请使用当前正在维护代码的团队维护的其他项目中使用的样式。
我使用过的代码库基本上都源自GCC和其他FSF软件,这意味着我的所有项目都在单独的行中使用了带有“{”的样式。我可以提出为什么“更好”的理由,但这是主观风格的问题。在项目内和团队中保持一致是客观更好。
答案 2 :(得分:0)
这完全是主观的。两者都很受欢迎。
答案 3 :(得分:0)
这里没有对错。这取决于您或您的团队/组织的偏好。
就支架而言,我现在的团队选择了选项B,但实际上我更喜欢选项A.
就个人而言,我会建议更多的间距,特别是在“for”和“if”之后,以及选项B上的更多缩进,以提高可读性。但是,这只是我的偏好。
答案 4 :(得分:0)
什么,没有中间立场?只有两个例子,每个都设计成一个(相对)极端的位置?
显然,你已经遗漏了一大堆中间例子,其中包含许多不同的格式规则。
如果你想不到至少十个变种,你真的不会付出任何努力。两种变体不足以关注细微差别。
如果你愿意,你可以 - 懒惰。一个体面的IDE将为您格式化。我使用Eclipse并为我格式化,这就是我在不考虑它的情况下使用它。
您还可以下载和阅读开源代码,并实际模拟您在那里找到的样式。这是一种不那么懒惰的方法,你必须阅读其他人的代码。
答案 5 :(得分:0)
我不确定是否有可能提出一个理由,为什么一个人比另一个人更好,不完全主观,只对一小部分项目有效。
我喜欢压缩的风格,它倾向于使代码更紧凑,因为我喜欢我的功能紧凑,适合屏幕,它有帮助。
它驱使其他人疯了,他们不喜欢看不到阻止开始并以自己的方式结束。我可以看出他们的观点。
通常它不是什么大问题,因为每个开发人员都使用他们自己的设置,我们让源控制系统以不可知的格式存储它(并不重要。)
当然是YMMV。
答案 6 :(得分:0)
正如一些人已经指出的那样,你应该使用代码库或团队已经使用的样式。
但是,如果你在大学或从未使用过使用花括号的语言,我建议将花括号放在自己的行上。我发现新的开发人员在与代码放在同一行时识别丢失的花括号可能会遇到问题。这可能与现代IDE没什么关系。
答案 7 :(得分:0)
当我年轻的时候,我常常相信所有这些问题都是意见问题,主观问题,最好留给个人品味。
随着年龄的增长,我的视力变得越来越消散。没有手术,使用眼镜或接触可以矫正散光 - 但校正远非完美。
散光使阅读更加困难,包括阅读代码。
对于像我这样有散光的人,identifiers_with_underscored_spacing
比IdentifiersWithCamelCaseWordBreaks
更容易阅读。
同样,对我来说,线条上的大括号比用括号共享一行的大括号更容易阅读。
因此,我推荐您提出的第二种风格,因为它更易于访问。