首先这是程序员问答论坛stackoverflow中“您最有争议的编程观点是什么?” 问题的高分问答的集锦，但这个帖子已经被删除了，也就是说死无对证。
1. 业余时间不以编程为乐的程序员，永远不会像以编程为乐的程序员一样优秀。
我认为即使是最聪明、最有天赋的人也不会成为真正优秀的程序员，除非他们把它当成比工作更重要的事情。也就是说，他们在业余时间做一些小项目，或者只是在业余时间搞很多不同的语言和想法。
作者 rustyshelf
2. 单元测试不会帮助你写出好的代码。
有单元测试的唯一原因是为了确保已经能用的代码不会出错。先写测试，或者先写代码再写测试都很可笑的。如果你先写测试再写代码，你甚至不知道边缘情况是什么。你可能会有通过测试的代码，但在不可预见的情况下仍然失败。而且，好的开发人员会保持较低耦合，这将使新代码的添加不太可能导致现有的东西出现问题。
作者：Chad Okere
3. 你唯一应该一直使用的 “最佳实践 “就是 “开动自己的脑筋”。
太多的人都赶时髦，试图把方法、模式、框架等强加到不值得的事情上。仅仅因为某些东西是新的，或者因为某个受人尊敬的人有一个观点，并不意味着它适合所有的人。
作者：Steven Robbins
4. 大多数代码中的注释其实是一种垃圾代码的重复。
我们花了大部分时间来维护别人(或我们自己)写的代码，而拙劣的、不正确的、过时的、误导性的注释一定是代码中最令人讨厌的人工制品的榜首。我想最终很多人都会把它们忽略掉，尤其是那些花盒怪兽。更好的做法是专注于使代码可读，必要时重构，并尽量减少习语和怪癖。另一方面，许多课程教导说注释几乎比代码本身更重要，导致下一行给 invoiceTotal 增加一个注释的风格。
作者：Ed Guiness
5. “上网查查 “未尝不可!
是的，我知道这触犯了一些人的利益，他们多年紧张的记忆和/或光荣的一摞编程书籍，开始被一个任何人都可以在几秒钟内访问的资源所取代，但你不应该对使用它的人持反对态度。我经常听到google解决问题的答案是批评的结果，这真的是没有意义的。
首先，必须承认，每个人都需要材料来参考。你不是什么都懂，你也需要查资料。承认了这一点，你从哪里得到的资料真的重要吗?你是在书上查的，还是在谷歌上查的，还是从一只会说话的青蛙那里听到的，这重要吗?不，一个正确的答案就是一个正确的答案。重要的是你理解了这些材料，把它作为成功的编程方案的手段，并且客户/你的雇主对结果满意。
作者：PhoenixRedeemer
6. 不是所有的程序员受到合理待遇。
很多时候，管理者认为开发人员A等效于开发人员B，只是因为他们的经验水平相同等等。实际上，一个开发人员的业绩可能是另一个开发人员的10倍甚至100倍。谈论这个问题在政治上是有风险的，但有时我觉得应该指出，即使几个团队成员看起来技术相当，但情况并不总是如此。我甚至看到过这样的情况：主要开发人员 “无可奈何”，而初级开发人员做了所有的实际工作–虽然我相信他们得到了赞美。
作者：Dmitri Nesteruk
7. 我不明白为什么人们认为Java是大学里最好的 “第一 “编程语言。
其一，我认为第一门编程语言应该是这样的，它强调的是学习控制流和变量，而不是对象和语法。其二，我相信没有在C / C++中调试内存泄漏经验的人不能完全理解Java带来的东西。另外，自然的进展应该是从 “我怎么能做这个 “到 “我怎么能找到能做那个的库”，而不是相反。
作者 Learning
8. 如果你只懂一门语言，不管你对它有多精通，你都不是一个伟大的程序员。
似乎有一种态度认为，一旦你真的擅长C#或Java或其他任何你开始学习的语言，那么这就是你所需要的。我不这样认为，因为我所学过的每一门语言都教会了我一些关于编程的新东西，这些知识再反哺工作。我认为，任何一个人如果把自己限制在一门语言上，就永远不会有好的表现。这也向我表明了某种缺乏好奇心和尝试的意愿，这不一定符合我期望在一个真正优秀的程序员身上找到的品质。
作者：glenatron
9. 偶尔写一些垃圾代码是可以的。
有时候，为了完成一个特定的任务，只需要一段快速而肮脏的垃圾代码。模式，ORM，SRP，不管是什么……在控制台搞一下或简单写个Web应用程序，写一些内联SQL，然后快速地完成需求。
作者：jfar
10. 打印语句是调试代码的有效方法。
我相信，通过使用System.out.println(或任何适合你的语言的打印语句)来调试你的代码是完全可行的。通常情况下，这可以比调试更快，而且你可以将打印的输出与应用程序的其他运行进行比较。只要确保在生产时删除打印语句(或者更好的是，将它们变成日志语句)。
作者：David
11. 你的工作就是让自己失业。
当你为你的雇主编写软件时，你所创建的任何软件都要以这样的方式编写，即它可以被任何开发人员拾起并以最小的努力理解。它设计得很好，写得清晰一致，格式干净，在需要的地方有文档，每天按预期构建，检查到仓库，并有适当的版本。
如果你被公交车撞了，下岗，被解雇，或者走下神坛，你的雇主应该能够在一瞬间通知你替换你，下一个人可以介入你的角色，拿起你的代码，顶多一周内就可以开始运行。如果他或她做不到这一点，那你就太失败了。有趣的是，我发现，有了这个目标，我对雇主来说更有价值。我越是努力成为一次性的人，对他们来说就越有价值。
作者：迈克-霍弗
12. Getters和Setters被过度使用。
我见过数以百万计的人声称公共字段是邪恶的，所以他们将其私有化，并为所有字段提供getter和setter。我相信这与将字段公开几乎是一样的，如果你使用线程(但一般情况下不是这样)或者如果你的访问者有业务/展示逻辑(至少是一些 “奇怪 “的东西)，也许会有一点不同。我并不赞成公共字段，但反对为每个字段建立一个getter/setter(或Property)，然后声称这样做是封装或信息隐藏……哈哈!我认为，这是不对的。
作者：Pablo Fernandez
13. 别拿SQL不当代码。
也就是说，就像你的C#、Java或其他喜欢的对象/程序语言一样，开发一种可读和可维护的格式化风格。我讨厌看到马虎的自由格式化的SQL代码。如果你在页面上看到两种样式的大括号时都会尖叫，那么当你看到自由格式化的SQL或模糊或混淆JOIN条件的SQL时，你为什么或为什么不尖叫呢?
作者：MustStayAnonymous
14. UML图被高度高估了。
当然有一些有用的图，比如复合模式的类图，但是很多UML图完全没有价值。
当然也有一些有用的图，比如复合模式的类图，但是很多UML图完全没有价值。
作者：Ludwig Wensauer
15. 可读性是最重要的。
可读性甚至比正确性更重要。如果它是可读的，它就很容易修复。也容易优化，容易改变，容易理解。而且希望其他开发者也能从中学到一些东西。
作者：Craig P. Motlin
16. XML被高估了。
我认为有太多的人从未经过思考，就跳上了XML的浪潮……XML用于网络的东西是很好的，因为它是为它设计的。否则，我认为一些问题定义和设计思想应该优先于任何使用它的决定。
作者：Over Rated
17. 软件开发也只是一份工作。
我很喜欢软件开发。在过去的几年里，我写了一个关于这个主题的系列博客。我在这里花了足够多的时间，有超过5000个信誉点。我在一家初创公司工作，每周工作时间通常为60小时，收入比我作为一个承包商要少得多，因为团队很棒，工作也很有趣。
但本质而言，这只是一份工作。它的重要性排在很多事情之下，比如家庭、我的女朋友、朋友、幸福等，如果有无限的现金供应，我肯定选择做的其他事情之下，比如骑摩托车、帆船游艇或者滑雪板。我觉得有时候很多开发者忘记了，开发只是让我们拥有生活中更重要的东西(通过做我们喜欢的事情来拥有)，而不是作为最终目标本身。
作者：Greg Beech
18. 如果你是一个开发人员，你应该会写代码。
(这不是废话吗，看完我不太相信)
去年我做了不少面试，我面试的部分应该是测试大家的思维方式，以及如何在白板上实现简单到中等的算法。我一开始的问题是这样的。
考虑到Pi可以用函数4*(1 – 1/3 + 1/5 – 1/7 +… )来估计，更多的项会带来更高的精度，请写一个函数，计算Pi的精度达到小数点后5位。
这是一个应该让你思考的问题，但对于一个经验丰富的开发人员来说，应该不是遥不可及的问题(用大约10行C#语言就可以回答)。然而，我们的许多(据说是经过机构预选的)候选人甚至无法开始回答这个问题，甚至无法解释他们如何去回答这个问题。所以过了一段时间后，我开始问一些比较简单的问题，比如。
假设圆的面积是Pi乘以半径的平方，写一个函数来计算圆的面积。
令人惊讶的是，超过一半的考生不会用任何语言写这个函数(我可以读懂大多数流行的语言，所以我让他们使用任何他们选择的语言，包括伪代码)
我们有 “C#开发人员 “不能用C#写这个函数。我对此感到很惊讶。我一直认为，开发人员应该能够写代码。现在看来，这是个有争议的观点。当然，在面试候选人中也是如此
作者：Greg Beech
19. 设计模式对好设计的伤害大于帮助。
软件设计，尤其是好的软件设计太多变了，无法用模式来有意义地捕捉，尤其是人们能真正记住的模式数量很少–而且这些模式太抽象了，人们真正能记住的不只是少数几个。所以它们没有什么帮助。而另一方面，太多人迷恋这个概念，并试图将模式应用到各个地方–通常，在所产生的代码中，你无法在所有(完全没有意义的)Singletons和Abstract Factories之间找到实际的设计。
作者：Michael Borgwardt
20. 代码越少越好
如果用户说 “就这(么点)?”，没有体现你的工作量，那就是做对了。相信我，你要把这当成对你的最高赞誉。
作者：Jas Panesar
