这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
其他回答
世界需要更多的goto
人们虔诚地避免goto，除了“我的教授告诉我goto不好”之外，没有其他理由。它们有一个目的，可以在很多地方极大地简化生产代码。
也就是说，在你所编写的99%的代码中，它们都是不必要的。
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
观点:显式变量声明是一件很棒的事情。
我永远无法理解让开发人员浪费大量时间追踪由变量名输入错误引起的运行时错误，而不是简单地让编译器/解释器捕捉它们的“智慧”。
没有人能给我更好的解释，“好吧，这节省了时间，因为我不需要写'int I;'。”Uhhhhh……是的，当然，但是追踪一个运行时错误需要多少时间呢?
汇编语言是最好的编程语言。
单元测试不会帮助你写出好的代码
进行单元测试的唯一原因是确保已经工作的代码不会崩溃。首先编写测试，或者为测试编写代码都是荒谬的。如果在编写代码之前编写测试，您甚至不知道边界情况是什么。您的代码可能通过了测试，但在不可预见的情况下仍然会失败。
此外，优秀的开发人员会保持较低的内聚性，这将使新代码的添加不太可能对现有内容造成问题。
事实上，我将进一步推广，
软件工程中的大多数“最佳实践”都是为了防止糟糕的程序员造成太大的破坏。
他们的作用是指导糟糕的开发人员，防止他们犯愚蠢的错误。当然，由于大多数开发人员都很糟糕，这是一件好事，但优秀的开发人员应该得到通过。
