这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
我认为使用try/catch异常处理比使用简单的返回代码和相关的公共消息传递结构来传递有用的错误消息更糟糕。
用try/catch块乱扔代码不是解决方案。
只是将异常传递到堆栈上，希望上面的内容会做正确的事情或 生成信息错误并不是解决方案。
认为您有机会系统地验证适当的异常处理程序可以解决透明对象或opague对象中可能出现的任何错误，这是不现实的。(还要考虑到后期绑定/外部库以及随着系统的发展，调用堆栈中不相关函数之间不必要的依赖关系)
返回代码的使用很简单，可以很容易地系统地验证覆盖范围，如果处理得当，就会迫使开发人员生成有用的错误消息，而不是太常见的堆栈转储和模糊的I/O异常，即使对最聪明的最终用户来说，这些异常也“异常”毫无意义。
--
我最后的反对意见是使用垃圾收集语言。不要误会我的意思。在某些情况下，我喜欢它们，但在服务器/MC系统中，它们在我看来没有位置。
GC并不是绝对正确的——即使是设计得非常好的GC算法也可能基于依赖关系图中不明显的循环引用而在对象上停留太长时间，甚至永远停留。
遵循一些简单模式并使用内存计算工具的非GC系统不会有这个问题，但在设计和测试方面需要比GC环境做更多的工作。这里的权衡是，在非GC测试期间，内存泄漏非常容易发现，而找到与GC相关的问题条件则要困难得多。
内存是便宜的，但当你泄露昂贵的对象，如事务句柄、同步对象、套接字连接……在我的环境中，如果不对软件描述进行重大的基本更改，那么您可以坐下来让语言为您操心，这种想法是不可想象的。
其他回答
对于一个优秀的程序员来说，语言不是问题。
这可能不是很有争议，但我听到很多其他程序员的抱怨，比如“为什么他们不都用delphi?”，“c#糟透了”，“如果他们强迫我用java，我就会换公司”等等。 我所认为的是，一个好的程序员是灵活的，能够用他一生中可能不得不学习的任何编程语言编写好的程序
我总是对的。
或者叫它讨论设计。但如果我提出了什么，你最好能证明我为什么错了，并提出一个你可以辩护的替代方案。
当然，这只有在我讲道理的时候才管用。幸运的是，我是。：）
单元测试不会帮助你写出好的代码
进行单元测试的唯一原因是确保已经工作的代码不会崩溃。首先编写测试，或者为测试编写代码都是荒谬的。如果在编写代码之前编写测试，您甚至不知道边界情况是什么。您的代码可能通过了测试，但在不可预见的情况下仍然会失败。
此外，优秀的开发人员会保持较低的内聚性，这将使新代码的添加不太可能对现有内容造成问题。
事实上，我将进一步推广，
软件工程中的大多数“最佳实践”都是为了防止糟糕的程序员造成太大的破坏。
他们的作用是指导糟糕的开发人员，防止他们犯愚蠢的错误。当然，由于大多数开发人员都很糟糕，这是一件好事，但优秀的开发人员应该得到通过。
当我声称代码只是我的设计的一种表达时，我经常被人大声叫嚷。我非常不喜欢看到许多开发人员在编写代码时“匆匆忙忙”地设计系统。
当其中一个牛仔从马上摔下来时所浪费的时间和精力是惊人的，而且他们遇到的问题十有八九只要前期设计工作就能解决。
我觉得现代方法没有强调设计在整个软件开发过程中的重要性。例如，当你甚至还没有审查你的设计时，对代码审查的重要性!这是疯狂。
使用匈牙利符号应处以死刑。
这已经足够有争议了;)
