你最有争议的编程意见是什么？
这绝对是主观的，但我想尽量避免它成为议论。 如果人们适当地对待它，我认为这可能是一个有趣的问题。
关于这个问题的想法来自我对“你恨你最喜欢的语言的五件事情是什么？ 问题 。 我认为C＃中的类应该被默认封闭 – 我不会把我的推理放在这个问题上，但我可以写一个更完整的解释来回答这个问题。 在评论的热烈讨论中，我感到惊讶（目前有25条评论）。
那么， 你们持有什么有争议的意见呢？ 我宁愿避免那种以相对较less的基础为基础（例如支撑）的相对虔诚的事物，但是例子可能包括诸如“unit testing实际上并不是非常有用”或“公共领域确实没有问题”的事情。 无论如何，重要的是（对我来说）是你有意见背后的理由。
请提出你的意见和推理 – 我会鼓励人们投赞成票和有趣的意见，不pipe你是否同意他们。
程序员如果不在业余时间编写代码，就永远不会像那样做。
我认为，即使是最聪明，最有才华的人也永远不会成为真正优秀的程序员，除非他们把它看作不仅仅是一份工作。 这意味着他们在一边做一些小项目，或者在业余时间只是混淆了很多不同的语言和想法。
（注意：我并不是说好的程序员除了编程之外别无他法，但是他们不仅仅是从9编程到5编程）
你应该始终使用的唯一的“最佳实践”是“使用你的大脑”。
太多的人跳过太多的绑架，试图强制方法，模式，框架等等，而不保证他们的东西。 只是因为有些东西是新的，或者是因为有人尊敬有意见，并不代表它适合所有人:)
编辑：只是为了澄清 – 我不认为人们应该忽略最佳实践，重视意见等只是人们不应该只是盲目跳上的东西没有想到为什么这个“东西”是如此之大，是适用于我在做什么，它带来了什么好处/缺点？
代码中的大多数注释实际上是代码重复的有害forms。
我们大部分的时间都是维护其他人（或我们自己）编写的代码，而糟糕的，不正确的，过时的，误导性的评论必须靠近代码中最恼人的工件列表的顶部。
我想最终很多人只是把它们弄出来，特别是那些花箱怪物。
更好地集中于使代码可读，必要时重构，最小化习语和古怪。
另一方面，很多课程教导说，评论比代码本身更重要，导致下一行添加一条发票总评论的风格。
“谷歌search”是好的！
是的，我知道这有些人在那里冒犯了他们多年的强烈记忆和/或光荣的一堆编程书籍开始落在资源之上，任何人都可以在几秒钟之内访问，但是你不应该这样对待人使用它。
我经常听到由于批评而导致的问题的答案，这实在是没有道理的。 首先，必须承认每个人都需要材料来参考。 你什么都不知道，你需要查找的东西。 承认这一点，你得到的信息真的很重要吗？ 如果你在一本书中查阅，在Google上查阅，或者从一个说话的青蛙听到你的幻觉，这有什么关系？ 没有。正确的答案是正确的答案。
重要的是，你了解这些材料，把它作为一个成功的编程解决scheme的结束手段，客户/你的雇主对结果感到满意。
（尽pipe如果你从幻觉的青蛙那里得到答案，你应该也可以得到一些帮助）
XML被高估了
在使用他们的大脑之前，我想太多的东西都跳到了XML的潮stream中去了。对于networking来说XML是非常棒的，因为它是为它devise的。 否则，我认为一些问题的定义和devise思想应该优先使用它的任何决定。
我的5美分
并不是所有的程序员都是平等的
很多时候pipe理者认为DeveloperA == DeveloperB仅仅是因为他们具有相同的经验水平等等。 实际上，一个开发者的性能可能是另一个开发者的10倍甚至100倍。
谈论这件事情在政治上是有风险的，但是有时候我想指出一点，即使几个团队成员看起来有相同的技能，情况并非总是如此。 我甚至还看到过，领导开发人员“超出希望”的情况，初级开发人员做了所有的实际工作 – 但我确信他们得到了信任。 🙂
我不明白为什么人们认为Java绝对是大学里最好的“第一”编程语言。
首先，我认为第一种编程语言应该是强调学习控制stream和variables的必要性，而不是对象和语法
另一方面，我相信在C / C ++中debugging内存泄漏的经验的人不能完全理解Java带来的东西。
另外，自然的进展应该是从“我怎么能做到这一点”到“我怎么能find做这个的图书馆”，而不是相反。
如果你只懂一种语言，不pipe你怎么知道，你也不是一个好的程序员。
似乎有一种态度说，一旦你真的擅长C＃或Java或任何其他语言，你开始学习那么这就是你所需要的。 我不相信 – 我学过的每一门语言都教给我一些关于编程的新东西，我已经把所有的东西都带回了我的工作中。 我认为，任何一个用一种语言来限制自己的人都不可能达到他们所能达到的水平。
这也表明，我缺乏一些好奇心和尝试的意愿，并不一定符合我期望在一个非常好的程序员中find的素质。
性能确实很重要。
打印语句是debugging代码的有效方法
我相信通过抛出System.out.println （或任何适用于您的语言的print语句）来debugging代码是完全正确的。 通常，这可以比debugging更快，并且可以将打印输出与应用程序的其他运行进行比较。
只要确保在生产时删除打印语句（或者更好地将它们转换为日志语句）
你的工作是让自己失去工作。
当您为您的雇主编写软件时，您创build的任何软件都应该以任何开发人员能够接受的方式编写，并且只需花费最less的精力即可理解。 它的devise清晰，一致，清晰，格式清晰，logging在需要的地方，按预期每日build立，检入资料库，并进行适当的版本pipe理。
如果你被公共汽车撞倒，解雇，解雇，或者离职，你的雇主应该能够立刻取代你，下一个人就可以进入你的职位，拿起你的代码，在一周之内运行。 如果他或她不能这样做，那么你失败了。
有趣的是，我发现实现这个目标让我对雇主更有价值。 我越努力成为一次性的，我就越有价值。
1）商业应用程序闹剧 ：
我认为整个“企业”框架的事情是烟雾缭绕。 J2EE，.NET，大多数Apache框架和大多数抽象来pipe理这样的事情，创造出比他们解决的复杂得多的事情。
采取任何常规的Java或.NET的ORM，或任何一个所谓的现代MVC框架，“魔法”来解决繁琐，简单的任务。 最终你会写出大量很难validation和写入的丑陋的XML样板文件。 您拥有大量的API，其中一半是集成其他API的工作，无法回收的接口以及仅仅为了克服Java和C＃的灵活性而需要的抽象类。 我们根本不需要那么多。
如果所有不同的应用程序服务器都有自己的描述符语法，过于复杂的数据库和组件产品？
这一点不是复杂性==不好，这是不必要的复杂==不好。 我曾经在大规模的企业安装中工作过，其中有一些是必要的，但是即使在大多数情况下，一些本地的脚本和一个简单的Web前端也是解决大多数用例所需要的。
我试图用简单的Web框架，开放源代码数据库和简单的编程结构来replace所有这些企业级应用程序。
2）所需的n年经验：
除非您需要顾问或技术人员来处理与应用程序，API或框架相关的特定问题，否则您并不需要在该应用程序中拥有5年经验的人员。 你需要的是一个能够阅读文档的开发人员/pipe理人员，无论你在做什么都有领域知识，谁可以快速学习。 如果你需要用某种语言进行开发，一个体面的开发者将在不到两个月的时间内完成。 如果你需要X Web服务器的pipe理员，两天之内他应该阅读手册页和新闻组，并加快速度。 less一点，那个人不值得他付出。
3）常见的“计算机科学”学位课程：
大部分的计算机科学和软件工程学位都是公牛。 如果你的第一个编程语言是Java或C＃，那么你做错了什么。 如果你没有得到几门充满代数和math的课程，那就错了。 如果你没有深入研究函数式编程，那么它是不完整的。 如果你不能将循环不variables应用于一个简单的循环，那么作为一个所谓的计算机科学家，你是不值得的。 如果您在x和y语言和面向对象方面有丰富的经验，那么就是充满了s ***。 一个真正的计算机科学家从它所使用的概念和语法的angular度来看待语言，并将编程方法学看作是众多其中之一，并且对于select新语言，devise方法或规范语言的基础哲学有着如此深入的了解是微不足道的。
吸气剂和固化剂被高度滥用
我已经看到数以百万计的人声称公共领域是邪恶的，所以他们把它们变成私人的，为所有的人提供获得者和制定者。 我相信这几乎与公开领域相同，如果你使用线程（但通常不是这样），或者如果你的访问器有业务/表示逻辑（至less有一些“奇怪”），可能会有所不同。
我不赞成公共领域，但是反对为他们每个人制作一个getter / setter（或Property），然后声称这样做是封装或信息隐藏 …哈！
更新：
这个答案在评论中引起了一些争议，所以我会尽量澄清一点（因为这是很多人提出的，所以我会保留原文）。
首先， 任何使用公共领域的人都应该受到监禁
现在，创build私有字段，然后使用IDE 为每个字段自动生成getter和setter， 几乎和使用公有字段一样糟糕 。
许多人认为：
private fields + public accessors == encapsulation
我说（自动或不自动）为你的领域的getter / setter对生成有效地反对所谓的封装，你正试图实现。
最后，让我引用鲍勃叔叔的话题（摘自“清洁守则”第六章）：
有一个原因，我们保持我们的variables私人。 我们不希望任何人依赖他们。 我们希望自由地改变他们的types或实施的一时兴起或冲动。 那么为什么很多程序员会自动将getter和setter添加到对象中，从而将他们的私有字段显示为公开的？
UML图被高估了
当然，还有一些有用的图，例如复合模式的类图 ，但是许多UML图完全没有价值。
意见：SQL是代码。 像这样对待它
也就是说，就像您的C＃，Java或其他喜欢的对象/过程语言一样，开发一种可读性和可维护性的格式化风格。
我讨厌当我看到马虎自由格式的SQL代码。 如果您在页面上看到两种花括号的大括号时发出尖叫，为什么或为什么当您看到自由格式化的SQL或SQL会模糊或混淆JOIN条件时不尖叫？
可读性是您的代码最重要的方面。
更甚于正确。 如果它是可读的，很容易修复。 优化也很容易，易于更改，易于理解。 希望其他开发人员也可以从中学到一些东西。
如果您是开发人员，则应该可以编写代码
去年我做了很多面试，对于面试来说，我应该testing一下人们的想法，以及他们如何在白板上实现简单到中等的algorithm。 我最初开始的问题如下：
考虑到使用函数4 *（1 – 1/3 + 1/5 – 1/7 + …）可以估算出更多的项，从而得到更高的精度，编写一个计算Pi的函数，精确到小数点后5位。
这是一个应该让你思考的问题，但是对于一个经验丰富的开发人员来说，这个问题是不应该的（可以用大约10行的C＃来回答）。 然而，我们很多（据说是由该机构预先筛选的）候选人甚至不能开始回答，甚至不能解释他们如何回答。 所以过了一段时间，我开始问简单的问题，如：
给定一个圆的面积由Pi乘以半径的平方，写一个函数来计算一个圆的面积。
令人惊讶的是，超过一半的候选人不能用任何语言编写这个函数（我可以阅读最stream行的语言，所以我让他们使用他们select的任何语言，包括伪代码）。 我们有“C＃开发人员”谁不能写在C＃中的这个function。
我对此感到惊讶。 我一直认为开发者应该能够编写代码。 现在看来，这是一个有争议的观点。 当然，这是面试候选人！
编辑：
关于第一个问题是好是坏，你是否应该在面试中提出这样复杂的问题，在讨论中有很多讨论。 我不打算在这里深入研究（这是一个全新的问题），除了说你基本上忽略了这个post的观点 。
是的，我说这个人不可能有什么进展，但是第二个问题是微不足道的 ，很多人也不能和这个进展！ 任何自称为开发者的人都应该能够在几秒钟之内将答案写入第二个答案，而不用考虑。 许多人不能。
匈牙利符号的使用应该被处以死刑。
这应该是有争议的;）
devise模式正在损害好的devise，而不是帮助它。
海事组织的软件devise，尤其是优秀的软件devise，实在太多了，无法用模式来有意义地捕捉，特别是人们实际记得的less数模式 – 而且对于人们来说太抽象了，以至于不能只记得一小撮。 所以他们没有太大的帮助
另一方面，有太多的人迷恋这个概念，并试图将模式应用于任何地方 – 通常，在所得到的代码中，您无法find所有（完全无意义的）单例和抽象工厂之间的实际devise。
更less的代码比更好！
如果用户说“就是这样？”，而且你的工作依然是隐形的，那么这样做是对的。 荣耀可以在其他地方find。
PHP糟透了;-)
certificate是在布丁。
unit testing不会帮助你编写好的代码
有unit testing的唯一原因是确保已经工作的代码不会中断。 先写testing，或者写testing代码是荒谬的。 如果你在代码之前写testing，你甚至不知道边界情况是什么。 您可以通过testing但仍然无法预料的情况下失败的代码。
此外，优秀的开发人员将保持低凝聚力，这将使新代码的添加不太可能导致现有材料的问题。
事实上，我会更进一步概括，
软件工程中的大部分“最佳实践”都是为了防止坏的程序员造成太大的损失 。
他们在那里手持不良的开发人员，不让他们犯错误。 当然，由于大多数开发者都不好，这是好事，但好的开发者应该得到通过。
写小方法。 程序员似乎喜欢在多个不同的事情上编写懒惰的方法。
我认为应该创build一个方法，无论你在哪里命名。
偶尔写一些垃圾代码是可以的
有时候，快速而脏的垃圾代码是完成特定任务所需要的。 模式，ORM，SRP，无论…抛出一个控制台或Web应用程序，写一些内联的SQL（感觉很好），并爆炸的要求。
代码==devise
我不是复杂的UML图和无尽的代码文档的粉丝。 在高级语言中，你的代码应该是可读的，可以理解的。 复杂的文档和图表实际上不再是用户友好的。
这是关于Code as Design的主题的文章。
软件开发只是一项工作
不要误解我的意思，我很喜欢软件开发。 过去几年我写了一篇关于这个主题的博客。 我已经花了足够的时间在这里有> 5000点的声望点。 而且我的创业时间通常是60个小时，比我承包商less得多，因为这个团队非常棒，工作很有趣。
但在事物的macros伟计划中，这只是一项工作。
在家庭，女朋友，朋友，幸福等诸多方面，它的重要性排在下面，如果我拥有无限量的现金，例如骑摩托车，帆船或单板滑雪，我宁愿做其他事情。
我想有时候很多开发者会忘记，开发只是让我们能够拥有更重要的事情（而让他们做我们喜欢的事情），而不是成为自己的最终目标。
我也认为在源代码控制中使用二进制文件没有问题，如果有充分理由的话。 如果我有一个程序集，我没有来源，也可能不一定在每个开发者机器上的相同位置，那么我通常会把它放在一个“二进制文件”目录中，并使用相对path在一个项目中引用它。
相当多的人似乎认为我应该在同一句话中甚至提到“源头控制”和“二元”这个利害关系。 我甚至知道哪些地方有严格的规定，说不能添加它们。
每个开发者都应该熟悉现代计算机的基本架构。 这也适用于面向虚拟机的开发人员（可能更多，因为他们已经被一次又一次地告诉他们不需要担心自己的内存pipe理等）
软件架构师/devise师被高估
作为一名开发人员，我讨厌软件架构师的想法。 他们基本上是不再全时代码的人，阅读杂志和文章，然后告诉你如何devise软件。 只有那些真正写软件的人才能做到这一点。 我不在乎5年前你是否是世界上最好的编程人员，在你成为架构师之前，你的意见对我来说是无用的。
那有争议的呢？
编辑（澄清）：我认为大多数软件架构师都是伟大的业务分析师（与客户交stream，编写需求，testing等），我只是认为他们没有devise软件，高层次或其他方面的地方。
没有“一刀切”的发展方式
我很惊讶这是一个有争议的观点，因为在我看来，这是常识。 不过，在stream行的博客上，有很多条目是推广“一刀切”的发展方式，所以我觉得我可能实际上是less数。
在我们所知道的任何信息之前， 任何项目都被视为正确的方法，比如使用testing驱动开发（TDD），域驱动devise（DDD），对象关系映射（ORM） ，敏捷（大写A），面向对象（OO）等等，涵盖了从方法到架构到组件的所有内容。 当然，所有这些都有很好的可销售的首字母缩略词。
人们似乎甚至把徽章放在他们的博客上，例如“我是testing驱动的”或类似的，就好像他们严格遵守单一的方法，无论项目的细节是什么，实际上是一件好事 。
事实并非如此。
select正确的方法和体系结构和组件等是应该在每个项目基础上完成的，并且不仅取决于正在进行的项目types和其独特需求，还取决于规模和能力你正在使用的团队。
