编程风格重要吗？有多重要？ [关闭]

Question

去年我正在对一个团队成员的代码进行故障排除，发现它缺少缩进和 cmets。我正在和他谈论这件事，告诉他这不是一个好主意，但他被冒犯了。他比我聪明，或者当然受过更多教育。

从那以后我发现他申请了微软，当他们让他做一个双向链表实现时，他没有缩进或 cmets 写它，说他没有时间担心样式。 （这是一封电子邮件提交，需要 2 小时才能完成）

微软没有给他回电话.....你认为他们如何回应，你会如何回应？

这里有任何来自 Microsoft 的人可以建议他们在这种情况下会做什么吗？

Answer 1

没有程序员是一座孤岛。有一天，有人将不得不阅读他们的代码。之前在这里重复过很多次：

总是像终结者一样编码 维护您的代码将是一个 知道你在哪里的暴力精神病患者 直播。 -- 马丁·戈尔丁 _(maybe)

也就是说，如果他们的风格足够好，那么在招聘程序员时还有其他更重要的事情需要评估。但是，如果他们完全拒绝使用 cmets 或试图让他们的代码对其他人可读，那就是破坏交易了。

Answer 2

不关心风格的开发人员就像不关心颜色的艺术家、画家。

Answer 3

代码由三个实体读取：计算机、程序员和最终的维护者。
样式和格式与计算机无关，可能对程序员很重要，但对维护者肯定很重要，他们必须尝试理解程序的功能。
拒绝通过使代码可读来适应其他开发人员是不尊重的。
使用有意义的变量名和 cmets 创建有组织的代码是对其他人的一种常见礼貌形式。

Answer 4

几乎没有不评论的借口，也没有不缩进的借口。缩进由大多数最优秀的编辑处理，评论应该成为 MS 可能想雇用的人的第二天性。

它们当然都是人们进入的学科（无论是自然地还是通过学校教育），所以没有表现出来，也许表明缺乏纪律，或者至少表现出缺乏纪律。

编辑：链接列表需要 2 小时？！我明白他的意思是现在……在剩下的一小时五十分钟内适应所有格式会非常困难！ （我只是在玩玩——我认为面试不仅仅是一个链接列表！）

Answer 5

编程风格很重要。评论更是如此。即使你一个人在自己的项目上工作，你也应该注释你的代码，因为一个月后你不会记得你做了什么以及为什么。如果您在一个团队中工作，那么不清楚、未格式化和未注释的代码可能会导致灾难。

Answer 6

我会尝试奉承他，告诉他因为他可以做比其他程序员更复杂的事情，所以他需要对它进行评论并很好地布局，以便我们其他人能够理解它。

我认为，如果有人在面试中对我表现出这种态度，我会非常谨慎地考虑聘用他。我敢肯定，即使是微软也需要团队成员。

Answer 7

没有标识和可读风格的编程就像写一本没有段落和分页符的书。这只是一大堆文字，我永远不会花时间去理解它。

我完全理解微软的反应——我也不会给他回电话。

Answer 8

格式化不需要任何时间。这是一个糟糕的借口。为暴力精神病患者完成后，让您的编辑对其进行格式化。

Answer 9

我会解雇他，但幸运的是，他永远不会真正被雇用。

我宁愿他花 2 个小时编写干净、几乎可以正常运行的代码，而不是让他把一些有效的东西拼凑在一起。

编程风格很重要，尤其是在团队合作时。
在支持由多人编写的遗留应用程序时，它变得至关重要。

作为专业人士的一部分，而不仅仅是一些脚本小子，关心代码。 这是关于意识到其他人会在六个月后阅读这段代码（甚至是你！）。因此，您应该使其尽可能易于维护。

Answer 10

在面试中，不缩进或评论您的代码是完全可以的。事实上，如果您有时间这样做，我会感到惊讶——我们通常不会给那么多时间。

但是，作为一般惯例，我完全希望您缩进代码并在必要时添加 cmets。事实上，我们的构建机器会在代码中包含制表符而不是空格等微小的事情上失败。

代码可读性很重要。就像没有人喜欢阅读一大段（而不是小的、结构化的段落）一样，没有人喜欢阅读一大段没有格式的代码。

Answer 11

我很难相信有人会认为没有缩进是个好主意。太傻了，如果他在采访中为我这样做，我也不会给他回电话。

评论有点灰暗，优秀的代码在很大程度上是自我记录的。如果您编写了出色的代码，那么 cmets 应该只出现在真正复杂且难以理解的地方。

Answer 12

当然，风格很重要。尤其是在涉及缩进和空格之类的事情时。代码应该很容易被人阅读，因为这是一个人以后必须维护该代码。代码的可读性越高，维护起来就越容易，代码的质量最终会变得越高。

有一个心理因素会影响代码风格。当代码“丑陋”且难以阅读/理解时，您希望减少对该代码的所有权，因此个人激励您尽力而为。随着代码变得更具可读性/易于理解，您对所做的工作感觉更好，并希望获得更多所有权。您对代码的所有权越多，编写更好的代码对个人来说就越重要。

至于微软如何回应，我会以完全相同的方式回应。我认为他们没有给他回电话的回应可能是完全合理的（除了缺乏代码风格之外，可能还有其他因素，尽管我确信这是一个贡献者）。

Answer 13

事实上，软件生命周期最长的阶段是维护。在那段时间里，它主要是由人类阅读和分析，试图修复它、重用它、增强它等。这是保持它易于阅读和理解的最佳理由。有人说他没有时间担心明显影响可读性的风格，这只是表明他作为软件工程师的不成熟。或者可能根本不了解软件生命周期。

Answer 14

编程风格很重要。干净的代码令人赏心悦目，并提高了程序的可维护性。因此它与程序本身的质量和架构直接相关。

即使在一种强制缩进的语言中，也可以用糟糕的风格破坏一切。因此，不好的样式可能不是缺少缩进或 cmets。实际上，我很少使用 cmets，我更喜欢 docstrings 和整体编写更好的文档。如果您确实发现其中有一些需要修复或想知道的地方，我会将 cmets 与您在代码中散布的小注释联系起来。

我宁愿把不好的风格看作是不让编程语言为你做一些事情。在一个或两个地方正确、干净地编写宏是真正的好风格而不是坏风格。

Answer 15

代码风格之所以重要还有另一个原因。它可以作为确定程序员专业程度的代理。正如孔雀的尾羽展示了他的健康和活力（一个不健康的有机体将无法投入稀缺的资源来建造一条长毛绒的尾巴），程序的风格可以揭示很多关于编写它的人的信息。

当我看到格式错误、命名约定不一致和 cmets 稀少的代码时，我会避开它，不仅因为这样的代码天生不可读，而且因为代码很可能在这个麻烦的表面下隐藏着更严重的问题。

Answer 16

我想知道任何体面的程序员如何在没有缩进的情况下编写代码，无论是在 IDE、vi、记事本、白板上还是在便利贴上完成。缩进代码应该是自然而然的。如果他上交的内容看起来像这样，我不会给他回电话（我只是从 Wikipedia 复制实现，重点是缺少缩进）：

struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev    := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}

Answer 17

如果您在缩进代码上花费的时间多于实际编写代码的时间，则可能会出现问题。但整个解决方案的源代码样式、约定和一致性很重要。

这就是我依靠工具来做到这一点的原因。 Resharper 允许我通过按 Ctrl+F、E 组合键重新格式化所有代码。

Answer 18

您的朋友需要正确处理他的优先事项，在我看来，我相信微软会比您想象的更关心。

Answer 19

我一直认为，您可以依靠的一件事是，在您离开后查看您的代码的人会认为您是个白痴。关键是要最大限度地延长从第一次查看代码到他们做出决定之间的时间。

良好的格式是增加 N 的一种方法，有用的 cmets 是另一种方法。

Answer 20

这完全取决于谁是源代码的目标受众。 正确答案是“其他程序员”（维护者等）。你的同事认为这并不重要，我完全理解为什么 MS 没有雇用他。如果有大公司愿意雇用他，我会感到惊讶！

我记得“ACM 通信”上出现了一篇题为“Typographic style is more than cosmetic”的旧文章，该文章对良好格式化代码对生产力的影响进行了实验。

他们带了一群程序员，并给他们一个测试来对他们进行排名。然后他们将小组分成两组，两组相同的任务：修改一个软件以添加一些功能。

只有第一组有一个格式很好的源代码可以处理，而其他组的相同代码版本相当混乱。

他们再次测量了他们的生产力，最终结果是第一组中最差的程序员比第二组中更好的程序员得分更高。

从那时起，我总是付出额外的努力使我的代码清晰易读。

对于那些对该主题感兴趣的人，我建议阅读有关文学编程、有意编程和其他相关概念的内容。

Answer 21

关于“风格”（我宁愿称之为“格式”）：这在很大程度上是个人品味的问题，但团队合作非常重要，定义了每个人都必须遵循的一些指导方针，如果出现以下情况，可以改变他/她的个人喜好需要（在 Eclipse 中，我们导出格式化程序配置，并通过按键我们将文件格式化）。 很快每个人都会习惯标准，阅读代码也不会那么疲劳了。

关于 cmets：我更喜欢为我的方法命名，但必须对最晦涩的两个部分进行评论。

Answer 22

您可以争辩说，编写良好的代码不需要 cmets，或者至少很少需要 cmets。但是没有缩进是不可接受的。编译器确实关心（在大多数情况下），但维护代码的人关心。

Answer 23

我不介意他没有立即放入 cmets。但是缩进很重要。当您编写代码时，它很少会在一次打字狂潮中线性出现。

不，即使在测试和可能调试代码之前，通常也需要进行大量编辑，并且能够清楚地看到代码结构很重要。

这让我想起了我职业生涯早期发生的一件事。我是一名初级程序员，另一位初级程序员向我寻求一些关于他的代码的帮助。我们当时正在使用 Pascal。他的代码一团糟。我以前见过没有缩进的代码，但从未见过随机缩进的代码。没有办法跟随它。

所以，我做的第一件事就是修复缩进。他得意地说。 “我不认为 那 会解决它！”。我回头看了看代码。这个错误现在很容易被发现，所以我只是指着它走开了。

Answer 24

编码风格相当重要。大多数主要的开发公司都有一份文档，其中定义了所需的命名约定、注释指南以及其他与代码样式和架构指南有关的小事。

所有这些都非常好，有助于营造一种工作环境，在这种环境中，团队成员可以对其同事的代码外观抱有良好的期望。

只要确保它不会降到经理级别，强迫开发人员在代码审查中进行更改，如下所示：

if( someBool() ) doSomething();
else doNothing();

这样的事情仅仅是因为他们“觉得”它是“更好”的风格：

if( someBool() )
{
    doSomething();
}
else
{
    doNothing();
}

请在风格要求方面有比个人偏好更好的理由，我们都可以更快乐。

Answer 25

在我看来，说风格不重要就像说拼写不重要一样。如果您的风格（或缺乏风格）导致可读性问题，那么团队将很难处理此人正在编写/编辑的文件。

同样，如果程序员没有花时间在注释块、函数名称等中正确拼写单词......它会导致其他开发人员试图破译代码时出现问题。我总是问自己，“自己，如果你在1周内看这个，你会明白吗？如果你明年再看，你还会明白吗？” （或者至少能够阅读文档/cmets 来记忆）。

对我来说，当您谈论将花括号放在 if 块的下一行而不是放在条件语句的末尾时，样式并不重要......只要它符合您的编码标准，内部是一致的，并且团队的其他成员使用相同的方法；话虽如此，我觉得如果它影响代码的可读性，样式就非常重要。

由于 MS 是一家如此大的公司，他们可能正在寻找既能解决问题又能团队合作的人。对我来说，如果有人说他们“没有时间做造型”，他们会觉得他们不是团队合作者。

好问题！

Answer 26

这就是需要编码标准的原因。团队应该遵守标准，即使这不是他们通常的编码方式。他可以学到很多东西来维护别人的烂摊子，就像我一样。 7000 行 C++ 以 C 风格编写，分为 7 个方法（大多数方法是 600 多行），许多包含转到方法内标签的一行宏。还有很多一行 if 语句，以及添加到这些和其他方法调用末尾的宏，因为您必须滚动才能看到它们。再加上可怕的变量名和不一致的括号风格，你会得到一个无法维护的混乱。积极的是它运作良好，我们多年来一直依赖它。

Answer 27

“他没有时间担心风格……”难怪他们没有给他回电话。他甚至没有参加面对面的采访，他已经拒绝做对他的要求？这是不通过任何职业面试的好方法。

风格是我们所做的一切所固有的。这不是覆盖。它不是一个附加组件。这不是福利。无论我们使用与否，它都存在。事物——程序、产品、你有什么——并没有因风格而得到改进；他们通过拥有良好的风格得到改进（与之相反的只是拥有糟糕的风格）。

从非常注重技术的角度来看的人的问题是，如果没有任何审美兴趣或欣赏来平衡它，就会认为“风格”是程序员不使用的工具； “风格”的意思是“留给 UI 或营销人员”。这根本不是真的。在努力做到最好的时候，你必须改进工作的各个方面。这不仅意味着执行，还意味着演示。

人类是视觉导向的生物。我们根据外观（漂亮女孩！闪亮包装！）来选择物品。

在明确宣布他没有时间追求风格时，他基本上给人的印象是他不是微软正在购买的闪亮包装。通过如此明显的预先道歉，他还让评估者更清楚地看到了他缺乏缩进和 cmets（尽管我相信他们不会仅仅因为他缺乏 cmets 而雇用他）。

Answer 28

嗯，有生活，然后有采访。

问问你的朋友 - 他会穿着破烂的牛仔裤和肮脏的 T 恤参加面试吗？

他在采访中的任务（无论采用何种形式）是为了给进行采访的人留下深刻印象。给他们留下深刻印象，让他们得到一份工作。

那么，如果申请程序员的工作，为什么这家伙会提交“破烂牛仔裤和肮脏的 T 恤”代码？

我真的希望这个人对编码风格、cmets 和空格有所了解。在那种情况下，他判断面试官更关心“正确”而不是“善良”（我的解释）。

但是 - 给定任务（链表？这对程序员来说应该很容易），看起来任务不仅仅是代码的“正确性”。

我怀疑面试官正在寻找很多东西，包括良好的编码实践（“忘掉”糟糕的编程实践比一开始就做好1000倍困难）。面试官可能也在寻找能表明主动性、良好假设能力，甚至可能是创造力或创造力的东西。

例如，有很多方法可以编写“正确”的链表，但有些方法（如使用递归）被认为比其他方法更“优雅”。

我怀疑你的朋友在这次采访中的几个层面都没有达到目标。

-R

Answer 29

据说项目生命周期的 80% 都花在了维护上。如果您的代码不可读，那么您肯定会为维护您的代码的人浪费大量时间，并且不可避免地会让他们对您产生邪恶的想法。

不过，据我所知，大多数程序员团队（有时甚至是整个公司）都有一个文档或其他东西来解释他们所遵循的代码约定和样式。因此，在您在那里工作的第一天，很容易将他们的规则输入到您的 IDE 中，并让它自动格式化您的代码，这样您就不必担心了。更好的是，您可能会找到愿意“导出”他们的 prefs 文件的人，因此只需单击几下，直到您在该公司编写的所有代码都被完美格式化。

话虽如此，您并不总是可以使用这些特定于团队的约定（例如，在面试中）。遵循一些有意义的基本约定总是一个好主意。根据您的语言，一个好主意是谷歌“yourLanguage 代码约定”并阅读基础知识。在面试的情况下，重要的是你遵循一些基本的指导方针，并有一个你坚持的格式风格。如果你在同一行的“else”语句后面加上括号，然后在下一行再写一次，你可能是在告诉面试官你不够关心和/或你没有足够的关心体验一种方式已成为您的习惯。

Answer 30

如果想在编写完源代码后丢弃它，可以忽略样式。这适用于您为任务制作的快速脚本，实际上只运行一次。另一方面，本应只运行一次的任务稍后会被重用的频率。

重用可能没问题，但以后会很难理解会发生什么。以后想修改代码，就没有样式了。

适当的样式有多重要，取决于您将使用和修改代码多长时间以及将使用多少代码。

如果您在团队中工作，请谈谈应该应用哪些样式。