这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
最新的设计模式往往是骗人的。正如之前在这个问题中所说的，过度使用设计模式对设计的危害远大于帮助。
如果我再听到一个人说“每个人都应该使用IOC”(或类似的废话)，我想我将被迫找到他们，并告诉他们他们方法的错误。
其他回答
成员变量不应该声明为private(在java中)
如果你声明了一些私有的东西，你就阻止了任何未来的开发人员从你的类派生和扩展功能。从本质上讲，通过编写“private”，您暗示您现在比任何未来的开发人员都更了解如何使用您的类。当你写“private”的时候，你应该写“protected”。
类永远不应该声明为final(在java中)
类似地，如果您将一个类声明为final(这将阻止它被扩展—阻止它被用作继承的基类)，那么您就意味着您比任何未来的程序员都更了解使用类的正确方法。这从来不是个好主意。你不是什么都知道。有人可能会提出一个完全合适的方法来扩展你没有想到的类。
Java bean是一个糟糕的想法。
java bean约定——将所有成员声明为private，然后为每个成员编写get()和set()方法——迫使程序员在不需要代码的地方编写样板、容易出错、冗长的代码。只要将public成员变量设为public!如果您需要更改实现，请相信您以后有能力更改它(提示:99%的情况下，您永远不会更改)。
在. net上开发不是编程。它只是把其他人的代码拼接在一起。
我的编码背景要求你了解硬件，这在我的行业中仍然是一个至关重要的要求，我认为高级语言只是简单地组装别人的工作。这并没有什么本质上的错误，但这是“编程”吗?
微软在为“开发人员”提供符号指令语法方面做了很多艰苦的工作。我现在似乎认识了越来越多的开发人员，他们在执行工作时似乎受到类的存在或不存在的限制。
我的观点来自于这样一个概念:作为一名程序员，你应该能够在你的平台允许的最低水平上编程。因此，如果您正在编写。net程序，那么您需要能够埋头苦干并找出解决方案，而不是依赖于其他人为您创建一个类。在我看来，这是一种懒惰，不符合“发展”的标准。
程序员需要与客户交流
一些程序员认为，他们不需要成为与客户交谈的人。对于你的公司来说，这是一种肯定的方式，可以写出一些绝对出色的东西，没有人知道它是用来做什么的，也没有人知道它是如何被使用的。
你不能指望产品经理和业务分析师做所有的决定。事实上，程序员应该在创建模块或特性的1000个(通常是小的)决策中做出990个，否则产品将永远不会发布!所以确保你的决定是明智的。了解你的客户，与他们一起工作，观察他们使用你的软件。
如果你想写出最好的代码，你希望人们使用它。对你的用户群感兴趣，向那些“愚蠢的傻瓜”学习。别害怕，他们会因此爱上你的。
程序员应该不惜一切代价避免通过继承隐藏方法。
In my experience, virtually every place I have ever seen inherited method hiding used it has caused problems. Method hiding results in objects behaving differently when accessed through a base type reference vs. a derived type reference - this is generally a Bad Thing. While many programmers are not formally aware of it, most intuitively expect that objects will adhere to the Liskov Substitution Principle. When objects violate this expectation, many of the assumptions inherent to object-oriented systems can begin to fray. The most egregious cases I've seen is when the hidden method alters the state of the object instance. In these cases, the behavior of the object can change in subtle ways that are difficult to debug and diagnose.
Ok, so there may be some infrequent cases where method hiding is actually useful and beneficial - like emulating return type covariance of methods in languages that don't support it. But the vast majority of time, when developers use method hiding it is either out of ignorance (or accident) or as a way to hack around some problem that probably deserves better design treatment. In general, the beneficial cases I've seen of method hiding (not to say there aren't others) is when a side-effect free method that returns some information is hidden by one that computes something more applicable to the calling context.
像c#这样的语言通过要求在隐藏基类方法的方法上使用new关键字进行了一些改进——至少有助于避免非自愿地使用方法隐藏。但我发现许多人仍然混淆了new和override的含义——特别是在简单的场景中，它们的行为看起来是相同的。如果像FxCop这样的工具实际上有内置的规则来识别方法隐藏的潜在不良使用，那就太好了。
顺便说一下，通过继承隐藏方法不应该与其他类型的隐藏(例如通过嵌套)相混淆，我认为嵌套是一种有效且有用的构造，潜在问题较少。
“评论是谎言”
注释不能运行，而且很容易被忽略。最好是用清晰的、由单元测试说明的重构代码来表达意图。(当然是编写TDD的单元测试…)
我们不写注释，因为它们很冗长，而且模糊了代码中真正发生的事情。如果你觉得需要注释——找出代码中不清楚的地方，然后重构/编写更清晰的测试，直到不需要注释……
．.． 我从极限编程中学到的东西(当然，假设你已经建立了清理代码的团队规范……)
