这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
最佳实践则不然。
其他回答
控制反转并不能消除依赖关系，但它确实很好地隐藏了依赖关系。
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
在我的工作场所，我一直试图引入更多的敏捷/XP开发习惯。持续设计是迄今为止我觉得阻力最大的一个。也许我不应该说“让我们召集所有的架构团队并射杀他们”……；）
手动停止程序是一种有效的、经过验证的查找性能问题的方法。
可信吗?对大多数人来说并非如此。真的吗?绝对的。
程序员的判断比必要的要多得多。
看看这些帖子中所有被认为是“邪恶”或“可怕”的事情吧。
程序员喜欢数据结构。
见证所有关于类、继承、私有与公共、内存管理等以及如何分析需求的讨论。
