这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
else是有害的。
其他回答
设计模式对优秀设计的伤害大于帮助。
IMO软件设计，尤其是优秀的软件设计，变化太大，无法在模式中有意义地捕捉，特别是在人们实际能记住的少量模式中——而且它们太抽象，人们实际上只能记住少数几个。所以他们帮不上什么忙。
另一方面，太多的人迷恋于这个概念，并试图在所有地方应用模式——通常，在生成的代码中，你无法在所有(完全没有意义的)单例和抽象工厂之间找到实际的设计。
实现IDisposable的类库指南是错误的。
我不经常分享这一点，但我相信IDisposable的默认实现的指导是完全错误的。
我的问题不是Dispose的过载，然后从终结器中删除项目，而是我鄙视终结器中释放托管资源的调用。我个人认为应该抛出异常(是的，在结束器线程上抛出异常会带来很多麻烦)。
其背后的原因是，如果您是IDisposable的客户端或服务器，那么您不能简单地将对象放置在那里等待最终确定。如果您这样做了，这是一个设计/实现缺陷(取决于它是如何放置的和/或它是如何暴露的)，因为您没有意识到您应该意识到的实例的生命周期。
我认为这种类型的错误/错误是在竞争条件/资源同步的水平上。不幸的是，通过调用Dispose的重载，该错误永远不会实现。
编辑:我写了一篇关于这个主题的博客文章，如果有人感兴趣的话:
http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for-IDisposable.aspx
观点:永远不要在“调试”和“发布”版本之间有不同的代码
主要原因是发布代码几乎从未经过测试。最好让在测试中运行的代码与在野外运行的代码相同。
如果没有远程调试器，就无法编写web应用程序
Web应用程序通常将客户端和服务器端多种语言之间的交互联系在一起，需要用户进行交互，并且通常包括第三方代码，这些代码可以是简单的API实现，也可以是复杂的框架。
我已经记不清有多少次，当我用一个不错的远程调试器进入并跟踪一个复杂的web应用程序中实际发生的事情时，另一个开发人员坐在我身边，看到他们惊讶地发现有这样的工具存在。通常情况下，即使在看到这些工具的实际运行后，他们仍然不愿意费心安装和设置这些工具。
你只是不能用打印语句调试一个重要的web应用程序。如果应用程序中的所有代码都不正确，则乘以10。
如果您的调试器可以逐步检查所有正在使用的语言，并显示正在发生的http事务，那就更好了。
没有Firebug就无法开发web应用程序
同理，一旦你用过Firebug(或非常接近Firebug的东西)，你就会对那些试图开发web应用程序的人既同情又恐惧。特别是Firebug显示计算样式，如果你还记得不使用它，花了几个小时随机更改各种CSS位，并添加“!重要的”在太多的地方搞笑你永远不会回去。
不要在数据库中使用stored proc。
它们最初的优点——安全性、抽象性、单一连接——都可以在集成了许多其他优点的orm的中间层中实现。
这无疑是有争议的。每次我提起这件事，人们就把我撕成碎片。
