这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
其他回答
编写小方法。程序员似乎喜欢编写冗长的方法，在这些方法中他们可以做多种不同的事情。
我认为应该在任何可以命名的地方创建方法。
软件开发人员、编码员、程序员、架构师之间没有区别……
我在酵母行业工作过10多种，但仍然觉得试图区分这些“角色”是绝对愚蠢的。你写代码?你是开发人员。你整天都在画漂亮的UML图。你是个…嗯. .我不知道你是谁，你可能只是想给别人留下好印象。(是的，我知道UML)。
.．.“澄清想法”不应该是开发者的唯一责任……是的，XKCD让我用了那个特定的短语…
我们经常会收到一些项目，这些项目都是在伪元类型特定的“代码”中指定的，如果你愿意这样称呼它的话。经常有产品经理为一个项目制定初始需求，并执行接近0%的基本逻辑验证。
我并不是说技术方法不应该由架构师制定，或者具体的实现不应该是开发人员的责任，而是说它应该是产品经理的需求，以确保他们的需求在逻辑上是可行的。
就我个人而言，我参与过太多“简单”的项目，这些项目在这里或那里遇到了一些范围渐变，然后遇到了与之前的需求相矛盾的“小”更改或功能添加——无论是含蓄的还是明确的。在这种情况下，要求做出近乎不可能的改变的人很容易对开发人员无法实现他们的梦想感到愤怒。
goto有一些(非常少)合法的用途(特别是在C中，作为异常处理的替身)。
软件因为缺乏多样性而糟糕透顶。无意冒犯任何种族，但当一个职业由不同种族和性别组成时，事情就会很顺利。看看过度使用不可再生能源就知道了。这很好，因为每个人都在贡献，而不仅仅是“刻板的人”
