这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
你不需要编写所有的程序
我厌倦了所有的事情，但所有的事情都需要塞进一个程序，这样总是更快。一切都需要基于网络，一切都需要通过计算机完成。请用你的笔和纸。它更快，更少维护。
其他回答
在产品代码中没有反射的位置
反射破坏了静态分析，包括重构工具和静态类型检查。反射还打破了开发人员对代码的正常假设。例如:向类中添加一个方法(它不会影响类中的其他方法)应该永远不会有任何影响，但是当使用反射时，其他一些代码段可能会“发现”新方法并决定调用它。实际上，确定这样的代码是否存在是很难的。
我确实认为在代码生成器中使用反射和测试是很好的。
是的，这确实意味着我试图避免使用反射的框架。(Java缺乏适当的编译时元编程支持，这太糟糕了)
意见:没有函数定义和返回类型会导致代码灵活易读。
这种观点可能更适用于解释型语言，而不是编译型语言。需要一个返回类型和一个函数参数列表，这对于智能感知来自动记录你的代码是很好的，但它们也是限制。
不要误解我的意思，我不是说扔掉返回类型，或者参数列表。他们有自己的位置。在90%的情况下，它们是利大于弊的。
在某些时候和场合，这是有用的。
聪明的程序员很危险
我花了更多的时间试图修复“聪明”程序员编写的代码。我宁愿有一个优秀的程序员，而不是一个特别聪明的程序员，他想通过编写只有他(或她)才能解释的代码来证明自己有多聪明。
大多数专业程序员都很糟糕
我遇到过太多为了谋生而做这份工作的人，他们对自己所做的事情很糟糕。蹩脚的代码，糟糕的沟通技巧，对新技术毫无兴趣。太多太多了……
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.
