这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
没有面向对象编程这种东西。
其他回答
依赖管理软件弊大于利
我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。
像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。
问题解决了，对吧?
错了。
下载库是依赖项管理的简单部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。
我不受欢迎的观点是:
如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。
同样地，如果列出从某个函数直接或间接调用的所有库(及其方法)所用的时间超过10秒，那么您在管理依赖关系方面做得很差。
您应该能够轻松回答“我的应用程序的哪些部分实际上依赖于库XYZ?”
当前的依赖关系管理工具弊大于利，因为它们很容易创建极其复杂的依赖关系图，而且它们实际上没有提供减少依赖关系或识别问题的功能。
我见过开发人员包含了10或20 MB的库，在项目中引入了数千个依赖类，只是为了消除几十行简单的自定义代码。
使用库和框架是很好的。但成本总是存在的，掩盖成本的工具本身就是有问题的。
此外，有时(注意:当然不总是)通过编写一些小的类来实现您所需要的东西比引入对大型通用库的依赖更好。
Web应用程序糟透了
我的网速很慢。我使用几乎所有不是谷歌的网站的经验至少是令人沮丧的。为什么现在没人写桌面应用了?哦，我明白了。没有人愿意学习操作系统是如何工作的。至少，不是Windows。上次你不得不处理WM_PAINT，你的头爆炸了。创建一个工作线程来执行一个长时间的任务(我的意思是，用Windows的方式来做)完全超出了你的能力。回调是什么鬼?哦，天哪!
垃圾收集糟透了
No, it actually doesn't. But it makes the programmers suck like nothing else. In college, the first language they taught us was Visual Basic (the original one). After that, there was another course where the teachers pretended they taught us C++. But the damage was done. Nobody actually knew how to use this esoteric keyword delete did. After testing our programs, we either got invalid address exceptions or memory leaks. Sometimes, we got both. Among the 1% of my faculty who can actually program, only one who can manage his memory by himself (at least, he pretends) and he's writing this rant. The rest write their programs in VB.NET, which, by definition, is a bad language.
动态类型糟糕透了
当然，除非您正在使用汇编程序(这是一种值得称赞的动态类型)。我的意思是动态解释性语言带来的开销让它们很糟糕。不要用不同的工具适合不同的工作这种愚蠢的论点。C语言是几乎所有事情的正确语言(它快速、强大、可移植)，当它不是(它不够快)时，总有内联汇编。
我可能会提出更多的咆哮，但那将是以后，不是现在。
实现IDisposable的类库指南是错误的。
我不经常分享这一点，但我相信IDisposable的默认实现的指导是完全错误的。
我的问题不是Dispose的过载，然后从终结器中删除项目，而是我鄙视终结器中释放托管资源的调用。我个人认为应该抛出异常(是的，在结束器线程上抛出异常会带来很多麻烦)。
其背后的原因是，如果您是IDisposable的客户端或服务器，那么您不能简单地将对象放置在那里等待最终确定。如果您这样做了，这是一个设计/实现缺陷(取决于它是如何放置的和/或它是如何暴露的)，因为您没有意识到您应该意识到的实例的生命周期。
我认为这种类型的错误/错误是在竞争条件/资源同步的水平上。不幸的是，通过调用Dispose的重载，该错误永远不会实现。
编辑:我写了一篇关于这个主题的博客文章，如果有人感兴趣的话:
http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for-IDisposable.aspx
没有“放之四海而皆准”的发展方法
我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在热门博客上有许多文章都在推广“一刀切”的开发方法，所以我认为我可能只是少数。
我所见过的被吹捧为任何项目的正确方法的东西——在了解任何关于它的信息之前——像使用测试驱动开发(TDD)、领域驱动设计(DDD)、对象关系映射(ORM)、敏捷(大A)、面向对象(OO)等等，等等，包括从方法到架构到组件的一切。当然，这些都是很有市场价值的首字母缩写。
人们甚至似乎在他们的博客上贴上徽章，比如“我是测试驱动的”或类似的东西，就好像他们严格坚持单一的方法，不管项目的细节是什么，实际上是一件好事。
它不是。
选择正确的方法、体系结构和组件，等等，是应该在每个项目的基础上完成的事情，不仅取决于您正在从事的项目的类型及其独特的需求，而且还取决于与您一起工作的团队的规模和能力。
计算机科学学位不会——也不应该——教你成为一名程序员。
编程是一门手艺，计算机科学是一个研究领域。你可以是一个伟大的程序员，也可以是一个糟糕的计算机科学家，也可以是一个伟大的计算机科学家，也可以是一个糟糕的程序员。了解其中的区别是很重要的。
如果你想成为一名程序员，学习Java。如果你想成为一名计算机科学家，至少要学习三种几乎完全不同的语言。例如(汇编语言，c语言，lisp语言，ruby语言，smalltalk语言)
