编程风格重要吗？有多重要？

Question

去年我正在对团队成员的代码进行故障排除，而且缺少缩进和评论。我跟他说说这不是一个好主意，但他得罪了。他比我更聪明，或者当然受过更多教育。

从那时起，我发现他申请了微软，当他们让他做双重链表实施时，他没有缩进或评论写道，说他没时间担心风格。 （这是一封电子邮件提交，有2个小时可以完成）

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

来自微软的任何人都可以建议他们在这种情况下会做些什么？

Answer 1

没有程序员是岛屿。有一天，有人必须阅读他们的代码。之前在这里重复了很多次：

  

始终将代码视为结束的人   维护你的代码将是一个   暴力的精神病患者谁知道你在哪里   住。    - Martin Golding _(maybe)

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

Answer 2

不关心风格的开发者就像艺术家，画家，不关心色彩。

Answer 3

没有评论的借口，没有不缩进的借口。缩进由大多数最好的编辑处理，评论应该是MS可能想聘用的人的第二天性。

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

编辑：链接列表需要2个小时？！我觉得他现在的意思是......在剩下的一小时内完成所有格式化，五十分钟就会非常艰难！ （我只是玩耍 - 我认为面试的内容多于链表！）

Answer 4

代码由三个实体读取：计算机，程序员，最终是维护者 样式和格式与计算机无关，可能对程序员很重要，但对维护人员来说肯定很重要，维护人员必须尝试理解程序的功能。
通过使代码可读而拒绝容纳其他开发人员是不尊重的 使用有意义的变量名称和注释创建有组织的代码是任何阅读它的人的共同礼貌。

Answer 5

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

Answer 6

格式化不需要任何时间。这是一个糟糕的借口。当你为暴力精神病患者做完时，让你的编辑格式化。

Answer 7

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

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

Answer 8

我会试着恭维他，告诉他，因为他可以做比其他程序员更复杂的事情，他需要对其进行评论并妥善安排，以便其他人能够理解它。

我想如果有人在采访中向我表达了这种态度，我会非常谨慎地考虑雇用他。我确信即使微软也想要团队成员。

Answer 9

我会解雇他，但幸运的是，他实际上从未被雇用过。

我希望他花了2个小时编写干净，几乎可以正常运行的代码，而不是让他把一些有用的东西打成一片。

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

作为专业人士的一部分，而不仅仅是一些脚本小子，正在关心代码。 这是关于意识到别人会在六个月之后阅读这段代码（也许就是你！）。因此，您应该尽可能简化维护。

Answer 10

在接受采访时，不要缩进或评论您的代码是完全可以的。事实上，如果你有时间这样做，我会感到惊讶 - 我们通常不会花那么多时间。

但是，作为一般惯例，我完全希望您缩进代码并在必要时添加注释。实际上，我们的构建机器会在诸如包含选项卡而不是代码中的空格之类的微小事情上失败。

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

Answer 11

代码风格很重要还有另一个原因。它可以作为确定程序员专业性的代理。正如孔雀的尾羽展示了他的健康和雄性（不健康的有机体无法将稀缺的资源用于建造长毛绒尾巴），程序的风格可以揭示出写作的人。

当我看到格式错误的代码具有不一致的命名约定和稀缺的评论时，我避开它不仅因为这样的代码本质上是不可读的，而且因为代码很可能在这个麻烦的表面下存在更糟糕的问题。 / p>

Answer 12

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

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 13

编程风格非常重要。清洁代码令人高兴，并提高了程序的可维护性。因此，它直接与程序本身的质量和架构联系在一起。

即使在一种强迫缩进的语言中，人们也可以用糟糕的风格打破一切。因此，糟糕的风格可能不会缺少缩进或评论。实际上，我很少使用评论，我更喜欢文档字符串和整体编写更好的文档。如果你真的看到那里有一些东西要修复或想知道，那么我会将评论与你在代码中传播的小笔记联系起来。

我宁愿看到糟糕的风格，因为不要让编程语言为你做一些事情。在一两个地方正确，干净利落的宏观是非常好的风格而不是坏事。

Answer 14

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

Answer 15

绝对，风格很重要。尤其是在缩进和空白等方面。代码应该易于被人阅读，因为它是一个必须在以后维护该代码的人。代码越易读，维护就越容易，代码的质量最终会越高。

有代码风格的心理因素。当代码“丑陋”并且难以阅读/理解时，您希望减少对该代码的所有权，因此没有个人激励来做您最好的工作。随着代码变得更易读/易于理解，您对自己已完成的工作感觉更好，并希望获得更多的所有权。您感觉代码的所有权越多，编写更好的代码就越重要。

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

Answer 16

我发现很难相信任何人都会认为没有缩进是一个好主意。这只是愚蠢的，如果他在接受采访时对我这样做，我也不会给他回电话。

评论有点灰白，伟大的代码在很大程度上是自我记录。如果你编写优秀的代码，那么评论应该只是在那些正在发生的事情真正复杂且难以理解的地方。

Answer 17

“他没有时间担心风格......”难怪他们没有给他回电话。他甚至没有接受面对面的采访，他已经拒绝做他所要求的事情了吗？这是一个不通过任何专业面试的好方法。

风格是我们所做的一切。这不是重叠。它不是附加组件。这不是一个好消息。无论我们是否使用它都存在。事物 - 程序，产品，你有什么 - 没有改进风格;他们通过GOOD风格得到改进（相反的风格只是风格不好）。

来自技术导向观点的人的问题在于，如果它没有被任何审美兴趣或欣赏所平衡，那么假设“风格”是程序员不使用的工具; “风格”的意思是“将其留给UI或营销人员”。这根本不是真的。在努力做到最好的时候，你必须改进工作的各个方面。这不仅意味着执行，还意味着演示。

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

在明确宣布他没有时间风格时，他基本上给人的印象是他不是微软购物的闪亮包装。通过这样一个明显的道歉，他也使评论员更加明显地缺乏缩进和评论（尽管我确信他们不会因为缺乏评论而聘请他）。

Answer 18

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

问问你的朋友 - 他会穿着破烂的牛仔裤和粗犷的T恤出席采访吗？

他在面试中的任务（无论格式如何）都是为了给面试人员留下深刻印象。给他们留下足够的印象来获得一份工作。

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

我真的希望这个人对编码风格，评论和空白有一些线索。在那种情况下，他做出了判决，称面试官更关心“正确”而不是“善”（我的解释）。

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

我怀疑面试官正在寻找很多东西，包括良好的编码习惯（1000％难以“忘掉”糟糕的编程习惯，而不是在开始时让他们正确）。面试官可能也在寻找能够表明主动性，良好假设，甚至是创造力或创造力的东西。

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

我怀疑你的朋友在这次访谈中错过了几个级别的标记。

-R

Answer 19

这就是需要编码标准的原因。即使不是通常的编码方式，团队也应该遵守标准。他可以学习很多实际上维护别人的混乱，就像我拥有的​​一样。 7000行C ++用C语言编写，分为7种方法（大多数方法是6​​00多行），许多一行宏包含方法中标签的getos。 if语句也有很多行，并且在这些和其他方法调用的末尾添加了宏，因为你必须滚动才能看到它们。添加到可怕的变量名称和不一致的包围样式，你会得到一个难以维护的混乱。积极的是它运作良好，我们多年来一直依赖它。

Answer 20

你的朋友需要把他的优先事项做好，在我看来，我相信微软会比你想象的更关心。

Answer 21

我一直觉得你可以依靠的一件事就是那些在你离开后看你的代码的人会认为你是个白痴。关键是要最大限度地延长首次查看代码与确定代码之间的时间。

良好的格式化是增加N的一种方式，有用的评论是另一种方式。

Answer 22

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

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

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

只有第一组获得了一个格式良好的源代码才能使用，而其他人则使用了相同代码的相当混乱的版本。

他们再次测量了他们的生产力，最终结果是第一组的WORST程序员得分高于第二组的BETTER程序员。

从那以后，我总是付出额外的努力使我的代码清晰，以供其他人阅读。

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

Answer 23

据说，项目生命周期的80％用于维护。如果您的代码不可读，那么无论是谁维护您的代码，都必然会浪费大量时间，并且不可避免地会让他们想到关于您的邪恶想法。

从我所看到的情况来看，大多数程序员团队（有时甚至是整个公司）都有一个文档或某些东西来解释他们所遵循的代码约定和样式。因此，在您工作的第一天，将您的规则输入IDE并让它自动格式化您的代码非常容易，因此您不必担心它。更好的是，你可能会找到愿意“导出”他们的prefs文件的人，所以只需点击几下，直到你在该公司写的所有代码都被完美地格式化。

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

Answer 24

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

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

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

MS是一家如此庞大的公司，他们可能正在寻找能成为解决问题者和团队合作者的人。那些声称他们“没有时间进行造型”的人会觉得我不是团队合作者。

好问题！

Answer 25

如果您花费更多时间来缩进代码而不是实际编写代码，则可能会出现问题。但是整个解决方案的源代码样式，约定和一致性非常重要。

这就是为什么我依靠一个工具来做到这一点。 Resharper允许我按Ctrl + F，E键组合重新格式化我的所有代码。

Answer 26

关于“风格”（我宁愿称之为“格式化”）：这在很大程度上取决于个人品味，但在团队中工作对于定义每个人必须遵循的一些指导方针非常重要，如果他/她的个人喜好如此弯曲需要（在Eclipse中我们导出格式化程序配置，并使用按键我们得到格式化的文件）。 很快每个人都会习惯标准，阅读代码将会非常疲惫。

关于评论：我更喜欢为我的方法提供良好的命名，但是对于最不起眼的部分的评论是强制性的。

Answer 27

你可以说，写得好的代码不需要评论，或者至少很少有评论。但缺乏缩进是不可接受的。编译器确实关心（在大多数情况下），但是维护代码的人会这样做。

Answer 28

编码风格非常重要。大多数主要开发公司都有一个文档，它定义了所需的命名约定，注释指南以及与代码样式和体系结构指南相关的其他一些小事。

所有这些都非常好，有助于促进一个工作环境，在这个环境中，团队成员可以对他们的同事代码看起来有很好的期望。

请确保它没有达到管理员的水平，迫使开发人员通过以下方式更改代码审核：

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

对于这样的事情只是因为他们“感觉”它是“更好”的风格：

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

请有理由比个人喜欢的风格要求更好，我们都会更开心。

Answer 29

我不介意他没有立即发表评论。但缩进很重要。当你编写代码时，它很少会在一次输入狂热时线性出现。

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

这让我想起了我职业生涯早期发生的一件事。我是一名初级程序员，另一名初级程序员请我帮忙解决他的代码问题。我们当时正在使用Pascal。他的代码很混乱。我以前见过没有缩进的代码，但从未见过随机缩进的代码。没有办法跟着它。

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

Answer 30

我倾向于认为编码风格更像是我们软件程序员的反映。

如果我们在世界上没有关心的情况下编写草率的代码，那么我会认为我们描绘的态度是我们不尊重其他团队成员，但如果我们花时间写一个这种风格是可以理解的，并且有意识地试图确保我们的代码清晰易读并且结构合理，那么我们当然会表明我们对我们的团队有尊重吗？

风格更多的是关于我们是谁，而不是关于我们所知道的。

Answer 31

IDE和编程编辑器以及代码重组器都在那里。商店应该采用适合其目的的风格，并根据需要使用重新格式化。

简而言之，缩进和分隔符的放置不再是一个大问题。

Answer 32

在面试的编码测试中没有显示评论就像参加考试而没有表现出任何工作一样！

当然，评论应该是对程序员策略和思考的见解之一吗？

Answer 33

我注意到代码就像一张蓝图。精心设计，美观，精湛的豪华住宅设计蓝图将具有良好的结构和实用性。代码应该是相同的。

Answer 34

我认为缩进是自然而然的。我只是这样做，每次我自动写东西。不这样做会让我感到困惑。

Answer 35

上面已经提到过几种观点。基本上，样式和注释有助于维护。

代码是为程序员（包括你自己！）编写的，而不是编译器。如果我们从不需要阅读代码，只需使用六角垫（就像一个真正的程序员！）就可以用它完成！ ： - ）

但事实上几乎不是这样。在代码的生命周期内，编译器可能总共花费几秒钟来处理它。但程序员可能会花费几天时间。如果难以阅读或理解，那些日子可能会增加到几周。努力应该用于使代码自我记录，但不要依赖它。如初。

缩进显示控制流程。一堆没有缩进的行可能有控制流，但这意味着你必须读取每一行来检测它：

if(someSituation) somethingElse++;

VS

if(someSituation)
    somethingElse++;

第二个版本在视觉上跳出来。您无需阅读和理解代码即可确定已做出决定。扫描一些代码以快速找到某些内容非常重要。

大多数IDE和编程编辑器都允许您立即缩进代码块。这很容易，你应该这样做只是为了确保你没有悬挂的“其他”或其他操作员顶空问题。缺乏缩进非常难以证明。

评论也很重要。如果评论与代码不符，那么它们都是错的（我不记得是谁先说了这个，但他/她已经死了！）。

首先列出代码，然后编码和调试，然后再次检查注释，我放入了注释块。我可能会发现我误解了问题（更改了注释）或者我可能已经实现了错误的操作（更改代码）。或者我可能会发现我重新实现了一个库函数（暂时将它全部注释掉，以防万一我需要做一些奇怪的事情）然后调用函数。

有时您必须使用名称错误的库函数。您可以说RTFM并继续前进，或者您可以进行摘要评论并保存下一个程序员（可能是您自己在6个月内）的一些努力。

// This allocates space for the message queue and initializes
// some OS overhead. All that remains after this is adjusting
// priority and content and then send the message.
prepareMessage(&myMessage);

此外，如果您花了两天的时间来处理错误并对代码进行了少量更改，那么在设计时很可能没有明显的变化。否则它本来就在那里！因此需要发表评论以防止将来某人将其改回“明显”的实施。

memset(&myStatus, 0, sizeof(myStatus));

// The size member must be set before getting current values.
// This is used by library function GetCurrentStatus() to infer
// a version of the status structure.
myStatus.length = sizeof(myStatus);

GetCurrentStatus(&myStatus);

Answer 36

我甚至不会阅读他的代码，如果它没有缩进，就不要记住它。缺乏时间是一个可怕的借口，在键入时缩短一段代码需要几秒钟......更不用说大多数编辑自动缩进的事实。评论也许他可能已经没时间了，但即便如此，这仍然是一个非常糟糕的借口。评论你刚才写的一段代码不需要很长时间。

Answer 37

我尝试使用IDE格式化样式。因此，我们避免了关于如何编写代码的新的和无聊的定义，因此，由于缩进和格式的差异，不必要的合并。

即使是最愚蠢的代码，也必须提供文档。有一个模板可以在代码中生成文档行。团队内部的标准化和组织协议是最好的风格。

Answer 38

编程风格不仅限于代码识别和注释 代码识别对于代码可读性确实非常重要。我从未见过易于阅读的非缩进代码:) 同样非常重要的是代码是不言自明的，只有当实现由于各种原因而变得密码或者代码没有清楚地反映出作者以这种方式编写的时候才应该使用注释。我看到很多过度评论的代码，我可以告诉你，几乎在每一行都看到评论就像阅读侮辱页面一样。
无论如何，我怀疑微软是否拒绝了你的同事只是因为他没有评论双链表实现。

Answer 39

评论是我认为的双刃剑，因为过多的评论肯定会导致可读性降低。杰夫撰写了一篇精彩的文章on this

相反，缩进从不会伤害并增加可读性。 这就是为什么这么多人喜欢Python的重要空白的原因之一。

Answer 40

我认为我们所判断的很多是外观或风格，如果没有缩进或评论，很难看到一段代码，并且看到它的天才。大多数人会看着它，并认为这太复杂了，让我们重写它。

我可能会在提交之前阅读Microsoft代码样式指南。就像你不会走进脏衣服的采访一样，我也不会提交无痕的不可读代码

是什么意思....编写新代码就像性，快速和令人兴奋......维护代码是照顾孩子，因为性，长期，困难，有时非常令人沮丧....哦奖励和乐趣...

Answer 41

我不希望受访者评论他们的代码（假设他们是在面试中当场写的）。如果我正在采访经验丰富的人，并且他们没有缩进代码，那肯定会对他们不利。我不希望缩进是完美的，或者是我喜欢的样式，或其他任何东西。但它最好缩进。这是编写代码的一部分。

如果我正在招募没有经验的人（而且我通常都是）那么这无所谓。但我也不会要求他们写一个双重链表。

Answer 42

强调可读性的风格很重要。非常重要。

许多程序员争论频率和评论的使用，但大多数人认为他们是需要的。

Answer 43

如果想在编写之后丢弃源代码，可以忽略样式。这适用于您为任务执行的快速脚本，它只运行一次。另一方面，它发生的频率，应该只运行一次的任务将在以后重复使用。

重用可能没问题，但稍后会很难理解会发生什么。如果你想稍后修改代码，你会在没有某种风格的情况下迷失。

正确样式的重要程度取决于您使用和修改代码的时间以及代码的使用时间。

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

Answer 44

当谈到申请工作时的编码时，我认为解雇候选人没有评论/缩进他写的代码是有点苛刻的，除非他被明确要求这样做。

Answer 45

否

编程风格绝对不重要。重要的是可维护性和可读性。

为了确保您保持正常，您必须使用同质且可读的代码格式强制执行您的团队。哪一个无所谓：你不能取悦任何人，并且有软件可以改变代码格式。

如果某种语言接受几种范例，请勿尝试仅选择一种语言。只要代码得到很好的评论并完成工作，谁关心它的人就会使用功能性或命令式的风格？