这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
复制/粘贴是万恶之源。
其他回答
依赖管理软件弊大于利
我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。
像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。
问题解决了，对吧?
错了。
下载库是依赖项管理的简单部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。
我不受欢迎的观点是:
如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。
同样地，如果列出从某个函数直接或间接调用的所有库(及其方法)所用的时间超过10秒，那么您在管理依赖关系方面做得很差。
您应该能够轻松回答“我的应用程序的哪些部分实际上依赖于库XYZ?”
当前的依赖关系管理工具弊大于利，因为它们很容易创建极其复杂的依赖关系图，而且它们实际上没有提供减少依赖关系或识别问题的功能。
我见过开发人员包含了10或20 MB的库，在项目中引入了数千个依赖类，只是为了消除几十行简单的自定义代码。
使用库和框架是很好的。但成本总是存在的，掩盖成本的工具本身就是有问题的。
此外，有时(注意:当然不总是)通过编写一些小的类来实现您所需要的东西比引入对大型通用库的依赖更好。
全局变量和/或单例变量本身并不邪恶
我来自更多的系统管理员，shell, Perl(和我的“真正的”编程)，PHP类型的背景;去年我被派去做Java开发工作。
单身是邪恶的。全球人太邪恶了，他们甚至不被允许。然而，Java有像AOP这样的东西，现在还有各种“依赖注入”框架(我们使用谷歌Guice)。AOP就不是这样了，但是DI的东西肯定会给你什么?全局变量。啊,谢谢。
意见:框架和第三方组件只能作为最后的手段。
我经常看到程序员立即选择一个框架来完成一项任务，而不学习它工作所需的底层方法。有些东西不可避免地会被打破，或者我们会发现我们没有考虑到的限制，我们会立即陷入困境，不得不重新思考系统的主要部分。只要经过仔细考虑，框架是可以使用的。
女性比男性更适合做程序员。
与我共事过的女性程序员不像男性那样拘谨于“她们的”代码。他们更容易接受批评和新想法。
在1970年1月1日之前，真和假是相反的……
