编程风格重要吗？ 如何重要？
去年，我正在解决一个团队成员的代码，缺乏缩进和评论。 我正在和他谈话，告诉他这不是一个好主意，但他得罪了。 他比我聪明，或者受过更多的教育。
从那以后，我发现他申请了微软，当他让他做一个双链表的实现时，他没有压缩或评论地写下来，表示他没有时间担心风格。 （这是一个电子邮件提交，其中有2个小时完成）
微软没有给他回电话…..你觉得他们如何回应，你会如何回应？
来自微软的任何人都可以build议他们在这种情况下会做什么？
没有程序员是一个岛屿。 有一天，他们将不得不阅读他们的代码。 在此之前曾多次重复过：
总是编码，如果最终维护你的代码的人将是一个暴力的精神病患者谁知道你住的地方。 – 马丁戈尔丁（也许）
也就是说，如果他们的风格是足够的，在聘用程序员时还有其他更重要的事情需要评估。 但是，如果他们完全拒绝使用评论或试图让他们的代码可读，这是一个破坏交易。
一个不关心风格的开发者就像一个不关心颜色的艺术家，画家。
代码由三个实体读取：计算机，程序员，最终维护者。
风格和格式与计算机无关，对程序员来说可能很重要，但对于维护人员来说，必须尝试和理解程序的function是非常重要的。
拒绝让代码可读的其他开发人员是不尊重的。
使用有意义的variables名称和注释来创build有组织的代码是读取它的任何人的一种常见的礼貌forms。
没有评论的借口，没有没有缩进。 缩进是由大多数最好的编辑来处理的，评论应该成为MS可能愿意雇用的人的第二本质。
他们当然都是人们进入（不pipe是自然的还是通过学校教育）的纪律，也许没有performance出纪律，或者至less是努力去expression。
编辑：2小时的链接列表？ 我现在看到他的意思了……在剩下的一个小时里，在所有的格式里面，五十分钟就会非常艰难！ （我只是在玩耍 – 我认为面试的内容比链表更多！）
编程风格非常重要。 评论更是如此。 即使你自己在自己的项目上工作，你也应该评论你的代码，因为一个月之后，你将不记得你做了什么，为什么。 而如果你在一个团队中工作，那么不清楚，没有格式化和没有注释的代码可能会导致一场灾难。
我会尝试奉承他，告诉他，因为他可以做比其他程序员更复杂的东西，他需要评论它，并很好地布置，使我们其他人可以理解它。
我想如果有人在面试中对我performance出那种态度，我会仔细考虑雇用他。 我相信即使是微软也想要团队合作。
没有身份和可读风格的编程就像写书没有段落和分页。 这只是一大堆文字，我不会花时间去理解它。
我完全理解微软的反应 – 我也不会再打电话给他。
我会开除他，但幸运的是，他永远不会被雇用。
我宁愿花2个小时写一些干净的，几乎可以正常运行的代码，而不愿意把它们放在一起。
编程风格很重要，特别是在团队工作时。
当支持由几个人编写的遗留应用程序时，它变得至关重要。
作为一名专业人士，而不仅仅是一些脚本小子，正在关注这些代码。 这是关于意识到别人会从现在起六个月阅读这些代码（也许甚至是你！）。 所以，你应该尽可能的容易维护。
在采访中，不要缩进或注释你的代码是完全正确的。 事实上，如果你有时间这样做，我会感到惊讶 – 我们通常不会花那么多时间。
然而，作为一般的做法，我完全希望你缩进你的代码并在必要时添加注释。 实际上，我们的编译机器将会在代码中包含制表符而不是空格的情况下失败。
代码的可读性很重要。 就像没有人喜欢阅读一个大段落（而不是小的，结构化的段落），没有人喜欢阅读一大块没有格式的代码。
我觉得很难相信任何人会认为没有缩进是一个好主意。 那简直是愚蠢的，如果他在采访中为我做了这个，我也不会回电话给他。
评论是一个小问题，伟大的代码很大程度上是自我logging。 如果你编写了很棒的代码，那么评论应该只是在那些正在发生的事情上真正复杂而难以遵循的地方。
绝对的，风格很重要。 特别是当涉及缩进和空白的东西。 代码应该容易被一个人阅读，因为它是一个必须稍后维护代码的人。 代码越可读，维护越容易，代码的质量将越高。
有一个心理因素来进入代码风格。 当代码是“丑陋”，很难阅读/理解，你想要较less的代码所有权，所以没有个人动机做你最好的工作。 随着代码变得更易读易懂，您对自己所做的工作感到满意，并希望获得更多的所有权。 你感觉代码的所有权越多，编写更好的代码越重要。
至于微软如何回应，我会以完全相同的方式作出回应。 我认为他们不回复他的回应可能是完全合理的（除了缺乏代码风格之外，可能还有其他因素，尽pipe我确信这是一个贡献者）。
那么事实是，它生命周期最长的软件生命周期阶段就是维护。 在这段时间里，大部分人都会通过阅读和分析来解决这个问题，重新使用它，增强它等等，这是保持易读性和可扩展性的最好理由。 有人说他没有时间担心风格，这明显影响了可读性，只能说明他作为软件工程师的不成熟。 或者根本不了解软件的生命周期。
编程风格非常重要。 清洁的代码让人眼前一亮，提高了程序的可维护性。 因此它直接与程序本身的质量和架构紧密相连。
即使用强制缩进的语言，也可以用坏风格打破一切。 不好的风格可能不会因此缺乏缩进或评论。 其实，我很less使用评论，我更喜欢文档和整体写作更好的文档。 如果你真的看到有什么东西需要解决或者想知道的话，我会把注释和你在代码中传播的小笔记联系起来。
我宁愿看到不好的风格，因为不让编程语言为你做一些你的东西。 适当的，干净的书面macros观在一个或两个地方是非常好的风格，而不是坏的。
代码风格是重要的还有另一个原因。 它可以作为确定程序员专业性的代理。 正如一只孔雀的尾羽performance出他的健康和性能（一个不健康的生物体将不能把稀less的资源投入build立一个毛绒尾巴），一个程序的风格可以揭示出写这个人的很多东西。
当我看到格式不正确的代码具有不一致的命名规则和稀缺的注释时，我不再使用它，这不仅因为这样的代码本质上是不可读的，而且代码很可能在这个麻烦的表面下隐藏更严重的问题。
格式化不需要任何时间。 这是一个糟糕的借口。 只要让你的编辑为了暴力的精神病患者而完成格式化。
我想知道任何一个像样的程序员如何在没有缩进的情况下编写代码，无论是在IDE，vi，记事本，白板还是贴子上都可以完成。 缩进代码应该是自然而然的。 如果他转过来的话，我不会打电话给他（我只是复制维基百科的实现，重点是缺乏缩进）：
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 } 如果您花费更多时间在缩进代码上，而不是实际编写代码，则可能会造成问题。 但是整个解决scheme中的源代码样式，约定和一致性非常重要。
这就是为什么我依靠一个工具来做到这一点。 Resharper允许我通过按Ctrl + F，E组合键来重新格式化我的所有代码。
你的朋友需要把他的优先权给对，在我看来，我相信微软会更关心你的想法。
我一直觉得，你可以指望的一件事是，在你离开后看看你的代码的人会认为你是个白痴。 关键是要最大限度地缩短从第一次查看代码到做出决定的时间。
良好的格式是增加N的一种方式，有用的评论是另一种。
这完全是源代码的目标用户的问题。 正确的答案是“其他程序员”（维护者等）。 你的同事认为这不重要，我完全理解MS为什么不雇用他。 如果有什么大公司会雇用他，我会感到惊讶的！
我记得在“ACM通讯”上刊登了一篇名为“ 印刷风格不仅仅是化妆品 ”的旧文章，对良好的格式化代码对生产力的影响进行了实验。
他们带了一群程序员，给他们一个排名的testing。 然后他们把这两个小组分成两组，分配相同的任务：修改一个软件来添加一些function。
只有第一组获得了格式良好的源代码才能工作，而其他人则使用相同代码的相当混乱的版本。
他们再次衡量他们的生产力，最终的结果是第一组的WORST程序员比第二组的BETTER程序员得分要好。
从那时起，我总是付出额外的努力，使自己的代码清晰可读，供其他人使用。
对于那些对这个话题感兴趣的人，我build议阅读有关文学编程，有意编程和其他相关概念。
关于“风格”（我更愿意称之为“格式化”）：这主要是个人品味的问题，但是在团队中工作对于每个人必须遵循的一些准则是非常重要的，如果需要的话，弯曲他/她的个人偏好Eclipse我们导出格式化程序configuration，并通过按键我们得到格式化的文件）。 很快，每个人都会习惯这个标准，阅读代码将会非常疲惫。
关于评论：我更喜欢我的方法的一个很好的命名，但在最不明确的部分两个评论是强制性的。
你可以争辩说，写得好的代码不需要评论，或者至less很less有评论。 但缺less缩进是不可接受的。 编译器确实在乎（在大多数情况下），但维护代码的人员却这么做。
我不介意，他没有立即发表评论。 但是缩进很重要。 当你编写代码的时候，它很less会在一个合适的打字狂热中线性地出现。
不，甚至在testing和可能的debugging代码之前，通常有很多编辑，能够清楚地看到代码结构是非常重要的。
这让我想起了我职业生涯早期发生的一件事。 我是一名初级程序员，另一名初级程序员要求我帮他的代码。 我们当时正在使用Pascal。 他的代码乱七八糟。 我以前看过没有缩进的代码，但从来没有看过随机缩进的代码。 没有办法遵循它。
所以，我做的第一件事是修复缩进。 他自鸣得意地说。 “我不认为这会解决它！” 我回头看了一下代码。 现在这个错误很容易被发现，所以我只是指着它走开了。
编码风格相当重要。 大多数主要的开发公司都有一个文档，它定义了所需的命名约定，评论指导方针以及与代码风格和体系结构指导方针有关的其他小事情。
所有这一切都是非常好的，有助于促进一个团队成员对他们的同事代码看起来会有好的期望的工作环境。
只要确保它不落在一个经理级别，迫使开发人员在代码审查中进行更改，如下所示：
if( someBool() ) doSomething(); else doNothing();
对于这样的事情，仅仅是因为他们“感觉”了“更好”的风格：
if( someBool() ) { doSomething(); } else { doNothing(); }
只是请有理由比个人偏好的风格要求，我们都可以更快乐。
在我看来，说风格不重要，就像说拼写不重要一样。 如果您的风格（或缺乏风格）导致可读性问题，那么团队将很难处理此人正在编写/编辑的文件。
同样，如果程序员没有花时间在注释块，函数名等上正确地拼写单词……这将会导致其他开发人员试图破译代码的问题。 我总是问自己，“自我，如果你在一周之内看这个，你会明白吗？明年你看，你还会明白吗？ （或者至less能够阅读文档/注释以点动记忆）。
对我来说，当你谈论把大括号放在你的if-block的下一行，而不是把它放在条件语句的末尾时，风格就不重要了……只要它符合你的编码标准，在内部是一致的，而其余的团队使用相同的方法; 说到这一点，我觉得风格是非常重要的，如果它影响到代码的可读性。
由于MS是一个如此大的公司，他们可能正在寻找一个可以成为问题解决者和团队成员的人。 有人说，他们“没有时间造型”会不会是一个团队的球员，对我来说。
很好的问题！
这就是为什么需要编码标准。 即使不是他们通常的代码，团队也应该坚持这个标准。 他可以学到很多东西来维持别人的混乱，就像我拥有的一样。 C ++使用C ++编写的7000行代码分为7种方法（大多数方法是600多行），在方法中有很多包含gotos标签的行macros。 还有很多一行if语句，以及macros添加到这些和其他方法调用的结尾，你不会看到，因为你必须滚动才能看到它们。 添加到可怕的variables名称和不一致的包围风格，你会得到一个难以维系的混乱。 积极的一面是它运作良好，而且我们多年来一直依赖它。
“他没有时间担心风格……”难怪他们没有给他回电话。 他甚至没有进行面对面的采访，他已经拒绝按照他的要求做什么了？ 这是不通过任何专业面试的好方法。
风格是我们所做的一切固有的。 这不是一个覆盖。 这不是一个附加。 这不是一个振作。 它是否存在我们是否使用它。 事情 – 程序，产品，你有什么 – 没有风格的改进; 他们有良好的风格（与之相反，只是风格不好）而得到改进。
从技术angular度来看，人们面临的问题是，如果没有任何审美的兴趣或欣赏，那么就认为“风格”是程序员不使用的工具; “风格”的意思是“把它留给用户界面或营销人员”。 这是不正确的。 为了争取最佳的工作，你必须改进工作的各个方面。 这意味着不仅仅是执行，而是介绍。
人类是视觉导向的生物。 我们根据他们的样子select一些东西（漂亮女孩！shiny的包装！）。
在明确宣布他没有时间进行创作的时候，他基本上给了他一个印象，那就是他并不是微软购买的那个shiny的软件包。 而且，通过这样一个明显的道歉之前，他也使得他缺乏对评价者更加明显的缩进和评论（尽pipe我相信他们不会因为缺乏独立评论而雇用他）。
那么，有生活，然后有采访。
问你的朋友 – 他会穿着破烂的牛仔裤和一件肮脏的T恤吗？
他在面试中的任务（无论是什么格式）都是为了打动面试人员。 给他们留下足够的印象来获得工作。
所以，如果申请一个程序员的工作，为什么在这个世界上这个人会提交“破烂的牛仔裤和肮脏的T恤”的代码？
我真的希望这个人对编码风格，评论和空白有一些线索。 在这种情况下，他作出了一个判断：面试官更关心“正确”而不是“善”（我的解释）。
但是 – 给定任务（链接列表？这对于程序员来说应该是很容易的），看起来这个任务远不止是代码的“正确性”。
我怀疑面试官正在寻找很多东西，包括良好的编程实践（“忘掉”糟糕的编程练习比在开始时让他们正确的做法要困难1000倍）。 面试官也可能正在寻找某种东西来表明主动性，好的假设，甚至创造力或创造性。
例如，编写链接列表的方式有很多种，但是有些（比如使用recursion）被认为比其他的更“优雅”。
我怀疑你的朋友在这个采访中几个级别都没有打上标记。
-R
据说一个项目的80％的寿命都花在维护上。 如果你的代码是不可读的，你肯定会浪费大量的时间来维护你的代码，不可避免地，你会让他们想到你的恶念。
然而，从我所看到的情况来看，大多数程序员团队（甚至整个公司）有一个文档或者一些解释代码约定和样式的东西。 因此，在您工作的第一天就可以轻松地将规则input到您的IDE中，并且只需要自动格式化代码，就不用担心这个问题。 更好的是，你可能会find一个愿意“导出”他们的prefs文件的人，所以这只是一个点击几下，直到所有的代码，你将永远写在该公司格式完美。
这就是说，你不会总是能够访问这些特定于团队的约定（例如，在面试中）。 遵循一些有意义的基本约定总是一个好主意。 根据你的语言，一个好主意是Google的“你的语言代码约定”，并阅读基础知识。 在面试的情况下，重要的是你遵循一些基本的准则，并有一个你坚持的格式风格。 如果您在同一行上的“else”语句之后再次将括号写在下一行中，那么您可能会告诉面试官，您并不十分关心和/或您没有足够的体验，一种方式已成为你的习惯。
强调可读性的风格很重要。 非常重要。
许多程序员争论频率和使用评论，但大多数人认为，他们是必要的。
