这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
如果不值得测试，就不值得构建
其他回答
开发人员过度使用数据库
通常情况下，开发人员在DBMS中存储的数据应该以代码或文件的形式存在。我曾经见过一个一列一行的表，它存储“系统密码”(与用户表分开)。我看到过存储在数据库中的常量。我见过的数据库足以让一个成年程序员哭出来。
这些讨厌的程序员对DBMS有一种神秘的敬畏——数据库可以做任何事情，但他们不知道它是如何工作的。dba实践一种黑魔法。它还允许责任转移:“数据库太慢了”，“是数据库做的”和其他借口是常见的。
如果不加检查，这些程序员就会继续开发数据库中的数据库，系统中的系统。(这个反模式有一个名字，但我忘了它是什么。)
对象不应该处于无效状态
不幸的是，许多ORM框架要求所有实体类都使用零参数构造函数，使用setter填充成员变量。在这些情况下，很难知道为了构造一个有效的对象必须调用哪些setter。
MyClass c = new MyClass(); // Object in invalid state. Doesn't have an ID.
c.setId(12345); // Now object is valid.
在我看来，一个对象不可能发现自己处于无效状态，类的API应该在每次方法调用后主动强制它的类不变量。
构造函数和突变方法应该原子地将对象从一种有效状态转换为另一种有效状态。这个好多了:
MyClass c = new MyClass(12345); // Object starts out valid. Stays valid.
作为一些库的使用者，在尝试使用一个对象之前跟踪是否调用了所有正确的setter是一件非常痛苦的事情，因为文档通常没有提供关于类契约的线索。
“不要从构造函数调用虚方法”。这只是有时PITA，但只是因为在c#中，我不能决定在构造函数中的哪个点调用基类的构造函数。为什么不呢?.NET框架允许它，那么c#有什么好的理由不允许它呢?
该死的!
学校教育毁掉创造力
*“废墟”指“潜在的废墟”
当然，上学是需要的!每个人在使用之前都需要学习一些东西——然而，如果我们不小心的话，你所有关于如何为特定的业务领域采取某种策略的伟大想法都很容易被扔进我们的大脑深处。
当你学习新事物、获得新技能时，你也会把自己的思维定势限制在这些新事物和新技能上，因为它们显然是“做事的方法”。作为人类，我们倾向于听从权威——无论是老师、顾问、同事，甚至是你喜欢的网站/论坛。我们应该时刻注意我们思维运作的“缺陷”。听别人说什么，但不要认为他们说的是理所当然的。对你收到的每一个新信息都要保持一种批判的观点。
而不是想“哇，这很聪明。我从现在开始就用它了”，我们应该想“哇，这很聪明。现在，我如何在我的个人技能和想法的工具箱中使用它?”
MS Access*是一个真正的开发工具，专业程序员可以毫无羞耻地使用它
仅仅因为某个平台吸引了自认为是程序员的黑客和秘书，就不应该玷污这个平台本身。每个平台都有其优点和缺点。
那些抱怨某些平台或工具或将其贬低为“玩具”的程序员更有可能对自己的手艺知之甚少，而不是他们的自我意识所说服的那样。对我来说，听到一个程序员抨击任何他们自己没有广泛使用过的环境是一种过度自信的表现。
*在这里插入任何恶意工具(VB, PHP等)。
