代码格式化的重要性，特别是间距[关闭]答案

【问题标题】：Importance of Code Formatting Specificly Spacing [closed]代码格式化的重要性，特别是间距[关闭]
【发布时间】：2010-10-26 14:45:56
【问题描述】：

这种形式的代码对于可读性有多重要：

public void DoStuff()
{
    var v = new Object();
    v.PropertyID = "abc";
    v.Type = "abc";
    v.Style = "abc";
    v.SetMode(Mode.Abc);
    v.Draw();
}

对比

public void DoStuff()
  {
    var v = new Object();
        v.PropertyID = "abc";
        v.Type = "abc";
      v.Style = "abc";
       v.SetMode(Mode.Abc);
   v.Draw();
    }

我最喜欢第一种风格，它使事情易于阅读，你会如何温和地引导人们走向前者并远离后者？还是不要？

【问题讨论】：

我不认为第二个示例是“样式”，它只是看起来有人使用了一些随机间距方案。
是的，就是这样（在 Bob 编辑之前）。问题是（或应该是），您将如何鼓励某人花时间将其代码格式化为第一种样式，以使下一个人受益，而不是让格式看起来好像是随机数量的每行都有不同的空格。
这应该是社区维基
只需在 Visual Studio 中设置您的默认规则并在保存之前始终按 Ctrl-K Ctrl-D，或者让 Visual Studio Power Commands 为您执行此操作:)

标签： coding-style code-formatting

【解决方案1】：

格式非常重要，但不是必需的。如果我看到像后者这样的代码，我往往会有点生气。如果您花时间编写代码，请确保花时间正确格式化。

【讨论】：

问题在于定义正确的含义。
我意识到格式对于编译器来说不是必需的，但我正在考虑下一个必须处理代码的人..

【解决方案2】：

第二种方式并不能很好地使用标签。避免它。

我还认为人们倾向于对这样的格式感到厌烦。一个月后会有另一个人出现并想要这种格式

public void DoStuff()
  {
    var v                = new Object();
        v.PropertyID     = "abc";
        v.Type           = "abc";
        v.Style          = "abc";
        v.SetMode        (Mode.Abc);
        v.Draw           ();
  }

这变得非常愚蠢而且很难处理。

如果人们是这样编码的，请质疑他们的推理和编程能力。

【讨论】：

【解决方案3】：

在第二个示例中，大括号的缩进不同。

间距对我阅读代码很重要。如果您在我的公司编写代码 - 我可能不得不在某个时候阅读它。如果您不格式化您的代码 - 我将使用自动格式化程序来获取我需要的内容。

【讨论】：

【解决方案4】：

人们真的编写看起来像后者的代码吗？这是可维护性的噩梦。

我认为你的代码格式约定是什么并不重要——更重要的是你始终遵循它们。前一个示例不一致，因此不可读且不可维护。

如果您在指导人们实现一致性方面遇到困难，让他们想象在一年内回头维护高度不一致的代码。

【讨论】：

【解决方案5】：

在团队中工作时，风格至关重要。所以不管你选择什么风格，只要确保每个人都同意它……然后执行该协议。将您的 IDE 设置为自动格式化您的代码.. 并确保每个人的 IDE 设置相同。

【讨论】：

【解决方案6】：

如果你想善良，请给他们 Code Complete 阅读。如果您想变得刻薄，请在他们的代码中引入类似这样的微妙错误：

if (x==y);
   DoSomething(); else
DoSomethingElse();
while(Whatever)
SomeFunction();

（如果他们在不到一天的时间内发现了这个错误，那你就不够隐秘了。）

【讨论】：

【解决方案7】：

我更喜欢你的间距，虽然我会做一些不同的事情。我相信您最重要的问题是如何说服某人您的方法是最好的：代码格式可能非常主观。有些人反对，因为它需要太多时间才能做到正确。其他人反对，因为团队没有任何编码标准。一些反对，因为感觉它被塞进了他们的脖子。

最好的方法是与您的团队合作，就您的特定方法是最佳实践达成共识。如果您是牵头人，或者您是个人贡献者，情况就是如此。

一旦团队共识被普遍接受（它可能不是普遍的），那么我发现代码审查是确保遵循团队实践的最佳场所。我建议你会发现同伴压力是鼓励其他人遵循公认的最佳实践的最有效方式。圈养往往是真实的。在没有共识的情况下，一个人很难在团队中推动这种事情。

这是我的一些相关 StackOverflow 答案

【讨论】：

【解决方案8】：

如果是我的代码，我会这样做：

public void DoStuff()
{
    var v = new Object();

    v.PropertyID = "abc";
    v.Type       = "abc";
    v.Style      = "abc";

    v.SetMode(Mode.Abc);
    v.Draw();
}

这样就清楚了哪些行是属性赋值，哪些是方法调用。

我也同意 Jamie 的回答，他说“格式非常重要，但不是必需的”。重要的是格式还不错，不会影响其他人的阅读能力。我不相信少数额外的制表符或换行符会对一个称职的程序员产生巨大的影响大部分时间。

【讨论】：

【解决方案9】：

正如其他人所说，第一个例子是规范；第二个与它不同。

此外，请确保处理同一组文件的每个人都对“选项卡”具有相同的约定。最好将其定义为多个空格，并确保每个人的文本编辑器和 IDE 都同意。

当三四个人在同一个 SVN 存储库中工作并使用不同的间距约定编辑每个文件时，这会很烦人。

【讨论】：