我们是应该鼓励有利于开发人员自主性的编码风格，还是鼓励开发人员保持一致性呢？

Question

开发人员用一行代码语句编写if/else块，如：

if (condition)
   // Do this one-line code
else
   // Do this one-line code

另一种是使用花括号对所有这些：

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

开发人员首先实例化一个对象，然后使用它：

HelperClass helper = new HelperClass();
helper.DoSomething();

另一个开发人员在一行中实例化并使用该对象：

new HelperClass().DoSomething();

开发人员更容易使用数组和for循环：

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

另一位写道：

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

我相信你知道我在说什么。我称它为编码风格(因为我不知道它叫什么)。但不管我们怎么称呼它，它是好的还是坏的？鼓励这样做会提高开发人员的生产力吗？我们是否应该要求开发人员按照我们告诉他们的方式编写代码，从而使整个系统变得一致？

Answer 1

编码标准文档是有用的。它是最有用的，当它足够短，任何人都可以记住整件事，没有太多的麻烦，当它不会给任何人带来太多的痛苦。

您如何选择在组织中缩进代码、大写名称、实现循环或注释代码并不那么重要；有帮助的部分是让每个人编写与其他人的代码大致相同的代码。

• 它避免了每次查看其他人的代码时都要花费一分钟重新校准您对大括号所在位置的期望。
• 它避免了几种不同样式的代码都在同一个文件中。
• 也许最重要的是，拥有一个书面标准可以避免在代码评审期间讨论编码实践。

同样，什么是标准并不像拥有某种简单、直接的标准那么重要。所以，把所有的开发人员都放在一个房间里，让他们来讨论标准应该是什么。这次会议可以无限期地继续下去，因此规则如下：

• 任何在会议结束前没有决定的事情都将由经理决定。
• 会议将在两个小时后结束，或者当有人开始大喊大叫或哭泣时，以第一名为准。
• 整个标准将符合(在合理的类型大小！)在一张或两张纸上，只有在绝对必要的情况下，才是双面的。

可以考虑采用来人呀、其他人和标准作为您自己的编码标准会议的起点，或者作为完全避免会议的一种方式。

一旦达成一致，开发人员应该能够(也应该期望)监管自己。偶尔偏离标准并不是什么大不了的事(甚至可能是有道理的)，但卑鄙的拒绝放弃某些最受欢迎的个人风格，转而支持标准，应该会导致立即把漏水的水管或其他东西搬到办公室。

德米安·布莱希特指的是皮棉工具。这些都是编码标准文档的完美补充。坚持编码风格标准只是件好事；坚持与危险实践相关的编码标准是很重要的。除了作者之外，没有人会检查每一行代码是否符合样式标准，但是您当然应该考虑在团队的工作流中构建一个lint工具来自动捕获可能的but。此外，该工具本身可以对公认的实践进行编码，这样您就不必在编码标准中单独列出它们；只需指定工具的配置即可。

注意：“编码标准”的想法并不是编程独有的。“编码标准”用于许多领域，有时是在组织内部，更多的是在整个行业或行业。下面是一些例子：

• 法律文件(如法院文件和笔录 )遵循特定格式。
• 剧本和剧本必须以特定的风格编写，才能被认真对待。
• 技术图纸通常必须有一个标准形式的标题块。
• 生平学格式是标准化的。

在每一种情况下(以及其他许多情况下)，有能力的从业者都可以很容易地理解不符合预期标准的“代码”。为什么这么多行业坚持为甚至不需要编译器解析的文档编写详细的需求？因为风格很重要。以标准的方式呈现信息，让读者完全专注于内容，使阅读更快，有助于理解，并减少错误。

Answer 2

风格不重要。

好了，我说了。

在经历了30年，数百个客户站点，以及那些年来估计了500名(或更多)团队成员的代码之后，我发现这种风格并不重要。

先让它起作用。

让它使用最优的资源量(即，正确的数据结构，正确的算法)。

在其他一切都解决了之后，对“风格”大惊小怪。小题大做的“风格”只与工具，从来没有手动。

Answer 3

有编码风格，也有编码气味。我一次也没发现：

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

我以前的雇主严格禁止使用没有大括号的多行if()。它被认为是“再做一次，你就被解雇了”类型的错误。允许的构造是

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

这是由一个错误造成的，就像我上面显示的那样，这个错误花了几个小时才找到使门户主页停止的地方。

有些事情你应该一直去做。就像switch()：

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

同时，键入：

     case 1:
         something();
     case 2:
         something();
     break;

如果不使用case关闭//fallthrough，则被认为是一个bug。

一般来说，有编码标准，这是准则，可以忽略，创造性地解释或修改为特定的需要。这是关于“气味”的章节，要严格遵守。