去年，我正在对团队成员的代码进行故障排除，但缺少缩进和注释。我在跟他谈论这件事，告诉他这不是一个好主意，但是他很生气。他比我聪明，或者当然是受过高等教育。

从那时起，我发现他申请了Microsoft，并且当他们让他执行双重链表实现时，他在编写时没有缩进或者注释，表明他没有时间担心样式。 (这是一封电子邮件提交，需要2个小时才能完成)

微软没有给他回电话.....我们如何看待他们的回应，我们将如何回应？

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

解决方案

我会尽力让他受宠若惊，告诉他，因为他可以做的事情比其他程序员还要复杂，所以他需要对其进行评论和布置，以便我们其他人都可以理解。

我认为，如果有人在面试中对我表现出这种态度，我会非常谨慎地考虑雇用他。我敢肯定，即使微软也希望团队合作。

在面试中，最好不要缩进或者注释代码。实际上，如果我们有时间这样做，我会感到很惊讶-我们通常不会花那么多时间。

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

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

没有任何理由不发表评论，没有任何理由不提出缩进。缩进由大多数最佳编辑处理，对于MS可能希望雇用的人来说，评论应作为第二天性。

他们当然都是人们都参加的两种学科(自然地或者通过学校)，因此或者不显示，或者表明缺乏学科，或者至少不努力表达。

编辑：2小时的链表？我知道他现在的意思是...在剩下的一小时五十分钟内适应所有格式将是非常困难的！ (我只是在玩耍，我认为采访中的内容比链接列表还多！)

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

我完全理解Microsoft的反应，我也不会再给他回电话。

编程风格非常重要。评论更是如此。即使我们自己在自己的项目上工作，也应该注释代码，因为一个月后，我们将不记得自己做了什么以及为什么这么做。而且，如果我们在团队中工作，那么不清楚，未格式化且未注释的代码可能会造成灾难。

我发现很难相信有人会认为没有缩进是个好主意。那真是愚蠢，如果他在面试中为我做到了，我也不会再打给他。

注释有点油腻，好的代码在很大程度上可以自我记录。如果我们编写了出色的代码，则注释仅应保留在实际发生的事情非常复杂且难以遵循的地方。

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

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

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

在申请工作时进行编码时，我认为解雇应聘者不要评论/缩进他编写的代码有点苛刻，除非明确要求他这样做。

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

Always code as if the guy who ends
  up maintaining your code will be a
  violent psychopath who knows where you
  live.
  -- Martin Golding (maybe)

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

如果要在编写后丢弃源代码，可以忽略样式。这适用于我们为任务编写的快速脚本，实际上只运行一次。另一方面，原本应该只运行一次的任务多久会在以后重用。

重用虽然可以，但是稍后将很难理解会发生什么。如果以后要修改代码，将会迷失方向。

正确的样式有多重要，取决于我们将使用和修改代码多长时间以及将使用多少代码。

如果我们在团队中工作，请说出应采用哪些样式。

朋友需要正确处理他的优先事项，在我看来，我认为微软会比我们认为的要多。

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

许多程序员对注释的频率和使用进行争论，但大多数人认为它们是必需的。

我会解雇他，但幸运的是，他实际上根本不会被录用。

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

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

成为专业人士的一部分，而不仅仅是一些脚本编写者，正在关心代码。
这是关于意识到六个月后会有其他人会阅读此代码(甚至我们也可以！)。因此，我们应该使其尽可能容易地进行维护。

我不希望受访者评论他们的代码(假设他们是在采访中当场编写的)。如果我采访的是一位经验丰富的人，但是他们没有缩进代码，那么那肯定对他们不利。我不希望压痕是完美的，或者是我喜欢的风格，或者其他任何东西。但是最好缩进。这是编写代码的一部分。

如果我招聘的是没有经验的人(通常是我)，那没关系。但是我也不会要求他们写一个双向链表。

绝对，风格很重要。特别是在缩进和空格等方面。代码应该易于被人阅读，因为稍后必须维护该代码。该代码越可读，则维护起来就越容易，并且该代码的质量最终将变得更高。

代码风格会影响心理因素。当代码"丑陋"且难以阅读/理解时，我们希望减少对该代码的所有权，因此，我们会缺乏个人动机去做最好的工作。随着代码变得更具可读性/易于理解，我们对所做的工作会感觉更好，并希望获得更多所有权。我们感觉到的代码所有权越多，编写更好的代码对个人而言就越重要。

至于微软的回应方式，我本来会以完全相同的方式回应。我认为他们不给他回电话的反应可能是完全合理的(而且可能还有其他原因，除了缺乏代码风格，尽管我确信这是一个原因)。

好吧，事实是，其中寿命最长的软件生命周期阶段就是维护。在这段时间内，大多数人都尝试阅读和分析它，以进行修复，重用，增强等。这是使其易于阅读和易于理解的最好原因。有人说他没有时间担心样式，这明显影响了可读性，这只表明他不成熟，是软件工程师。或者，也许根本不了解软件生命周期。

我认为我们判断的大部分内容是外观或者样式，很难在没有缩进或者注释的情况下查看一段代码并看到其中的天才。大多数人会看着它，认为这太过复杂了，让我们重写一下。

在提交之前，我可能会阅读Microsoft代码样式指南。就像我们不会接受脏衣服的采访一样，我不会提交无法识别的代码

怎么说？...编写新代码就像性爱一样，快速而令人兴奋...维护代码可以照顾由于性，长，难，有时令人沮丧而引起的孩子……。乐于助人和乐趣也...

不

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

为了确保我们按时进行，我们必须使用统一且易读的代码格式来强制团队。哪一个无关紧要：我们无法取悦任何人，并且有用于更改代码格式的软件。

如果一种语言接受多种范例，请不要只选择一种范例。只要对代码进行了很好的注释并能胜任工作，谁会在乎它使用的是功能性还是命令式风格？

编程风格非常重要。干净的代码使我们眼前一亮，并提高了程序的可维护性。因此，它直接与程序本身的质量和体系结构绑定在一起。

即使使用一种强制缩进的语言，也确实可以用不好的风格破坏一切。因此，不良的风格可能不会缺少缩进或者注释。实际上，我很少使用注释，我更喜欢docstrings和总体上编写更好的文档。如果我们确实看到其中有需要修复或者怀疑的地方，则会将注释与我们在代码中散布的小注释相关联。

我宁愿看到不好的风格，不要让编程语言为我们做一些事情。在一个或者两个地方正确，整洁地编写宏实际上是好的样式，而不是坏的样式。

我一直认为，我们可以依靠的一件事是，在我们离开后查看代码的人会认为我们是个白痴。关键是最大程度地缩短首次查看代码与确定代码之间的时间。

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

源代码的目标受众是谁，这一切都是问题。
正确的答案是"其他程序员"(维护人员等)。同事认为这并不重要，我完全理解MS为什么不雇用他。如果有任何一家大公司会雇用他，我会感到惊讶！

我记得在" ACM通讯"上刊登了一篇题为"印刷风格比装饰更重要"的老文章，该文章对格式良好的代码对生产力的影响进行了实验。

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

只是第一组可以使用格式良好的源代码来工作，而其他组则具有相同代码的相当混乱的版本。

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

从那时起，我一直在努力使代码清晰易读，以供其他人阅读。

对于那些对该主题感兴趣的人，建议阅读有关识字编程，有意编程和其他相关概念的文章。

我认为评论是一把双刃剑，因为过多的评论肯定会导致可读性降低。杰夫为此写了一篇很棒的文章

相反，缩进永远不会损害和增加可读性。
这就是为什么这么多人喜欢Python具有巨大空白的原因之一。

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

代码样式很重要的另一个原因。它可以充当确定程序员专业水平的代理。正如孔雀的尾巴羽毛展示出他的健康和活力(不健康的有机体无法将稀缺的资源投入到建造长毛绒的尾巴上)一样，程序的风格可以揭示出很多有关编写它的人。

当我看到格式不一致的格式，带有不一致的命名约定和稀缺注释的代码时，我会回避它，这不仅是因为此类代码本来就不可读，而且还因为该代码很可能在此麻烦的表面下隐藏了更严重的问题。

关于"风格"(我宁愿称其为"格式")：这在很大程度上取决于个人喜好，但是在团队中工作非常重要，它定义了每个人都必须遵循的一些准则，并在需要时改变个人偏好在Eclipse中，我们导出格式化程序配置，并通过按键将文件格式化)。
很快，每个人都将习惯于该标准，阅读代码的疲劳将大大减轻。

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

我们可以辩解说，编写良好的代码不需要注释，或者至少不需要注释。但是缺乏缩进是不能接受的。编译器确实在乎(在大多数情况下)，但是维护代码的人却在乎。

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

即使是最笨拙的代码，也必须提供文档。最好有一个模板来在代码内部生成文档行。团队内部的标准化和组织协议是最好的方式。

不关心样式的开发人员就像不关心颜色的艺术家，画家一样。

格式化不需要任何时间。这是一个卑鄙的借口。出于暴力心理变态，请让编辑器在格式化后对其进行格式化。

我不介意他没有立即发表评论。但是缩进很重要。当我们编写代码时，很少会因键入狂潮而线性出现。

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

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

因此，我要做的第一件事就是修复缩进。他自鸣得意地说。 "我认为这不会解决问题！"。我回头看了一下代码。现在很容易发现该错误，因此我只是指出该错误并走开了。

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

所有这些都非常好，并有助于建立一个工作环境，使团队成员可以对同事的代码有很好的期望。

只要确保它不会降到迫使开发人员对代码审查进行更改的经理级别即可，例如：

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

仅仅因为它们"感觉"到其"更好"的样式就可以了：

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

请提供比个人喜好更好的理由来满足风格要求，我们都可以更快乐。

在我看来，说风格不重要就像在说拼写不重要。如果风格(或者缺乏风格)引起可读性问题，那么团队将很难处理此人正在编写/编辑的文件。

同样，如果程序员不花时间在注释块，函数名称等中正确拼写单词，则会导致其他开发人员尝试破译代码。我总是问自己："自我，如果我们在1周内看一下，我们会理解吗？如果我们明年看，我们是否仍然了解？" (或者至少能够阅读文档/评论来唤起记忆)。

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

鉴于MS是一家如此庞大的公司，他们可能正在寻找可以成为问题解决者和团队合作者的人。在我看来，有人说他们"没有时间进行样式设计"时，他们会遇到不是团队成员的情况。

好问题！

我想知道任何体面的程序员如何在不缩进的情况下编写代码，无论是在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
}

如果没有缩进，我什至不会阅读他的代码，不要介意对其进行标记。缺乏时间是一个可怕的借口，在我们键入代码时缩进代码需要几秒钟的时间……更不用说大多数编辑器都会自动缩进这一事实。评论也许他可能没时间了，但是即使如此，这仍然是一个很糟糕的借口。评论我们刚刚编写的一段代码并不需要很长时间。

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

简而言之，分隔符的缩进和放置不再重要。

在面试的编码测试中不显示评论就像参加考试并且不显示任何工作！

当然，注释应该是对程序员策略和思想的见解之一？

我注意到代码就像一个蓝图。精心设计，精美，精巧的豪华住宅设计蓝图将被结构化和有益。代码应相同。

我认为缩进是自然而然的。每当我自动写东西时，我就这样做。不这样做会使我感到困惑。

这就是为什么需要编码标准的原因。团队应该遵守标准，即使标准不是他们通常的编码方式也是如此。他可以从实际维护别人的混乱中学习很多东西，例如我所拥有的东西。 7000行C ++以C样式编写，分为7种方法(大多数方法为600多行)，其中很多都是一行的宏，这些宏包含方法中的标签。在语句和其他方法调用的末尾添加了很多if语句和宏，我们将看不到它们，因为我们必须滚动才能看到它们。再加上可怕的变量名和不一致的括号样式，我们将获得无法维护的混乱局面。积极的一点是，它运作良好，并且我们多年来一直依靠它。

上面已经提到了一些对此的看法。基本上，样式和注释有助于维护。

代码是为程序员(包括我们自己！)而不是为编译器编写的。如果我们永远不需要阅读代码，只需用六角垫(像真正的程序员一样)将其打孔并完成即可！ :-)

但是，几乎从来没有这样。在代码的整个生命周期中，编译器可能总共花费几秒钟来处理它。但是程序员可能要花几天的时间。如果难以阅读或者理解，那几天可能会增加到几周。应该花大力气使代码自我记录，但不要依赖它。曾经。

缩进显示控制流程。一堆没有缩进的行可能具有控制流，但这意味着我们必须阅读每一行才能检测到它：

if(someSituation) somethingElse++;

与

if(someSituation)
    somethingElse++;

第二个版本从视觉上跳出来。我们无需阅读和理解代码即可了解已做出决定。扫描某些代码以快速查找内容时，这一点非常重要。

大多数IDE和编程编辑器将允许我们立即缩进一段代码。这很容易，我们只需要确保没有悬而未决的" else"或者其他运算符顶空问题就可以了。缺乏缩进很难证明。

评论也很重要。如果注释与代码不匹配，那么它们都是错误的(我不记得是谁先说了这个，但是他/他已经死了！)。

在首先布置代码，然后进行代码和调试，然后再次检查注释时，我放入了一个注释块。我可能发现我误解了该问题(更改了注释)，或者实现了错误的内容(更改了代码)。或者，我可能会发现我已经重新实现了一个库函数(暂时将其全部注释掉，以防万一我需要做一些奇怪的事情)并放入对该函数的调用。

有时，我们必须使用命名错误的库函数。我们可以说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);

此外，如果我们花了2天的时间解决了一个错误并在代码中进行了少量更改，则很有可能在设计时该更改并不明显。否则，它会排在第一位！因此，需要提供注释，以防止将来有人将其更改回"显而易见的"实现。

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);

"他没有时间去担心风格……"难怪他们没有给他回电话。他甚至没有参加面对面的采访，而且他已经拒绝执行对他的要求了吗？这是不通过任何专业面试的好方法。

风格是我们所做的每一件事所固有的。它不是覆盖物。这不是一个添加组件。这不是振作。无论是否使用它，都存在。事物程序，产品，我们没有通过风格改进的东西；通过具有良好的风格(与之相反，只是具有不良的风格)可以对它们进行改进。

从非常注重技术的角度出发的人们所面临的问题是，如果它没有被美学上的兴趣或者欣赏所抵消，则假定"样式"是程序员不使用的工具； "样式"表示"将其留给用户界面或者营销人员"。这根本不是真的。在努力做到最好时，我们必须改进工作的各个方面。这不仅意味着执行，还意味着展示。

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

在明确宣布自己没有时间进行时尚设计时，他基本上给人的印象是他不是微软要购买的闪亮包装。通过如此明显的道歉，他也使缩进和评论的缺乏对评估者更加明显(尽管我确信他们不会因为他缺乏评论而聘请他)。

好吧，有生活，然后有访谈。

问朋友，他会穿着破烂的牛仔裤和肮脏的T恤露面吗？

他在面试中的任务(无论采用哪种格式)都是要给进行面试的人留下深刻的印象。给他们留下深刻的印象，以得到一份工作。

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

我真的希望这个人对编码风格，注释和空白有所了解。在这种情况下，他做出了判断，即访问者更加关注"正当"而不是"善良"(我的解释)。

但是给定任务(链表？对于程序员来说应该很容易)，看来任务远不只是代码的"正确性"。

我怀疑面试官在寻找很多东西，包括良好的编码习惯("学习"不良的编程习惯比一开始就搞错要困难1000倍)。面试官可能还在寻找能说明主动性，做出良好假设，甚至可能具有创造力或者创造力的东西。

例如，有许多写链接列表的方法"正确"，但是某些方法(如使用递归)被认为比其他方法更"优雅"。

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

-R

据说项目的整个生命周期的80％都花在了维护上。如果代码不可读，那么我们肯定会浪费大量时间给任何维护我们代码的人，并且不可避免地，我们将使他们对想法感到邪恶。

但是，从我所看到的来看，大多数程序员团队(有时甚至是整个公司)都有一份文档或者一些说明他们遵循的代码约定和样式的文件。因此，在那里工作的第一天就很容易将其规则输入到IDE中，并使它自动格式化代码，因此我们不必担心。甚至更好的是，我们可能会找到一个愿意"导出"其prefs文件的人，因此只需单击几下，直到我们将在该公司编写的所有代码都经过完美格式化即可。

话虽如此，我们将永远无法访问这些特定于团队的约定(例如，在采访中)。遵循一些有意义的基本约定总是一个好主意。根据语言，一个不错的主意是使用Google的"语言代码约定"并阅读基础知识。在面试情况下，重要的是要遵循一些基本准则，并要遵循一种格式化样式。如果我们在同一行中的" else"语句之后做过一次括号，然后又在下一行中写下，我们可能是在告诉面试官我们不太在意和/或者我们没有足够的钱。体验一种方法已成为习惯。

我倾向于认为编码风格实际上更能反映出我们是那种软件程序员。

如果我们在编写程序时不小心，那么我会认为我们表现出一种不尊重其他团队成员的态度，但是如果我们花时间以一种可以理解的方式编写代码，并且有意识地尝试确保我们的代码清晰易读，结构正确，那么我们肯定会表现出对团队的尊重吗？

风格更多地是关于我们是谁，而真正的少是关于我们所知道的。