基本代码布局问题

Question

嗨，我有一个简单的问题，我问了 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
        }
    }
}

或

B)

for(int i=0;i<8;i++){
 for(int p=0;p<8;p++){
  if(array[i][p]->Equals(String)){
                    //Do Stuff
                }
        }
}

谢谢， 蒂姆

Answer 1

存在多个已发布的样式指南 - 例如，Google 的位于此处，它规定了功能：

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，< a href="http://geosoft.no/development/cppstyle.html#Layout" rel="nofollow noreferrer">geosoft，或您喜欢的任何其他来源（列出了更多此处）。

Answer 2

在实践中的几乎所有情况下，都有一个明确的答案：使用您正在使用的代码库中当前使用的样式。如果您要开始一个新项目，请使用当前在由维护您的代码的团队维护的其他项目中使用的样式。

我使用过的代码库很大程度上源于 GCC 和其他 FSF 软件，这意味着我的所有项目都使用了单独行中带有“{”的样式。我可以提出为什么“更好”的理由，但这是主观风格的问题。在项目内和团队内保持一致客观上更好。

Answer 3

这完全是主观的。两者都很受欢迎。

Answer 4

这里没有对错之分。这取决于您或您的团队/组织的偏好。

就大括号而言，我当前的团队选择了选项 B，但我实际上更喜欢选项 A。就

我个人而言，我建议在“for”和“if”之后多一点间距，并在选项 B 上多一点缩进，为了可读性。但是，这只是我的偏好。

Answer 5

什么，没有中间立场？只是两个例子，每个例子都旨在采取（相对）极端的立场？

显然，您遗漏了一大堆中间示例，其中有很多格式规则略有不同的内容。

如果你想不出至少十个以上的变体，那么你就没有真正投入任何精力。两种变体不足以关注细微差别。

如果你愿意的话，你可以偷懒。一个像样的 IDE 会为你格式化。我使用 Eclipse 及其为我提供的格式，这就是我在使用时根本不考虑它。

您还可以下载和阅读开源代码，并实际模拟您在那里找到的样式。这是一种不那么懒惰的方法，你必须阅读别人的代码。

Answer 6

我不确定是否有可能找出一个比另一个更好的理由，这些理由不是完全主观的，并且只对一小部分项目有效。

我喜欢压缩风格，它往往会使代码更加紧凑，而且因为我喜欢我的函数紧凑并适合屏幕，所以它会有所帮助。

但这会让其他人发疯，他们不喜欢看到一个块在自己的线上开始和结束。我明白他们的观点。

通常这没什么大不了的，因为每个开发人员都使用自己的设置，我们让源代码控制系统以不可知的格式存储它（哪一种并不重要）。

当然YMMV。

Answer 7

正如一些人已经指出的那样，您应该使用代码库或团队已经使用的样式。

但是，如果您在大学或从未使用过使用大括号的语言，我建议将大括号放在自己的行上。我发现，当新开发人员将大括号与代码放在同一行时，在识别缺失的大括号时可能会遇到问题。对于现代 IDE 来说，这可能不是什么大问题。

Answer 8

当我年轻的时候，我曾经相信所有这些问题都是观点问题，主观的，最好留给个人品味。

随着年龄的增长，我的视力变得越来越散光。如果不进行手术，散光可以使用眼镜或隐形眼镜来矫正，但矫正效果远非完美。

散光使阅读变得更加困难，包括阅读代码。

对于像我这样患有散光的人来说，identifiers_with_underscored_spacing 比 IdentifiersWithCamelCaseWordBreaks 更容易阅读。

同样，对我来说，单独的行上的大括号比与代码共享一行的大括号更容易阅读。

因此我推荐您提出的第二种样式，因为它更容易访问。