这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
Null引用应该从OO语言中删除
从Java和c#的背景来看，从一个方法中返回null来表示失败是很正常的，我已经得出结论，null会导致很多可以避免的问题。语言设计者只要从代码中消除空引用，就可以删除与nullrefernceexception相关的一整类错误。
Additionally, when I call a method, I have no way of knowing whether that method can return null references unless I actually dig in the implementation. I'd like to see more languages follow F#'s model for handling nulls: F# doesn't allow programmers to return null references (at least for classes compiled in F#), instead it requires programmers to represent empty objects using option types. The nice thing about this design is how useful information, such as whether a function can return null references, is propagated through the type system: functions which return a type 'a have a different return type than functions which return 'a option.
其他回答
初级程序员在被允许实际编写或修改代码之前，应该被分配做几个月的对象/模块设计和设计维护。
太多的程序员/开发人员在工作了5年或10年之后，还没有理解好的设计的要素。当他们想要超越编写和维护代码时，这可能会让他们陷入瘫痪。
软件就像厕纸。你花的越少，它就越麻烦。
也就是说，外包很少是一个好主意。
我一直认为这是真的，但直到最近我才真正知道它的程度。我最近一直在“维护”(即“修复”)一些离岸代码，这是一个巨大的混乱。我们公司的成本很容易就超过了内部开发的差额。
企业外部的人对你的业务模式了解较少，因此不会很好地为企业内部的系统编程。此外，他们知道他们不必支持它，所以除了半途而废之外，没有动力去做任何事情。
并不是所有的程序员都生而平等
管理人员经常认为DeveloperA == DeveloperB仅仅是因为它们具有相同的经验水平等等。事实上，一个开发人员的性能可能是另一个开发人员的10倍甚至100倍。
谈论它在政治上是有风险的，但有时我想指出，即使几个团队成员可能看起来具有相同的技能，但情况并不总是如此。我甚至见过这样的情况:首席开发人员“毫无希望”，而初级开发人员承担了所有实际工作——尽管如此，我还是确保他们得到了荣誉。：）
在我的工作场所，我一直试图引入更多的敏捷/XP开发习惯。持续设计是迄今为止我觉得阻力最大的一个。也许我不应该说“让我们召集所有的架构团队并射杀他们”……；）
观点:单元测试不需要预先编写，有时甚至根本不需要。
推理:开发人员不擅长测试他们自己的代码。我们所做的。这就是为什么我们通常有测试团队或QA团队。
大多数情况下，我们编写的代码与其他需要单独测试的代码交织在一起，因此我们最终会跳过模式框框来提供可测试性。并不是说这些模式不好，而是它们有时会增加不必要的复杂性，所有这些都是为了单元测试……
．.． 这通常是行不通的。编写一个全面的单元测试需要大量的时间。通常是我们不愿意付出的时间。测试越全面，如果测试对象的接口发生变化，就会变得越脆弱，迫使重写不再编译的测试。
