这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
不要在数据库中使用stored proc。
它们最初的优点——安全性、抽象性、单一连接——都可以在集成了许多其他优点的orm的中间层中实现。
这无疑是有争议的。每次我提起这件事，人们就把我撕成碎片。
其他回答
前期设计——不要因为兴奋而开始写代码
我见过很多设计糟糕的应用程序，因为开发人员太兴奋了，以至于他们直接打开白页开始写代码。我知道在开发生命周期中事情会发生变化。但是，如果应用程序具有多种不同的布局和开发方法(从一种形式到另一种形式，从一种方法到另一种方法)，则很难处理这些应用程序。
如果没有明确定义任务以及计划如何编写任务，就很难达到应用程序要处理的目标。花点时间(而不是仅仅5分钟)，确保在开始编码之前，你已经尽可能多地布局了它。这样你就可以避免顶替你的人不得不承担的意大利面条般的混乱。
如果语言已经公开了实际类型，就不要为基本类型使用关键字。在c#中，这将指bool (Boolean)， int (Int32)， float (Single)， long (Int64)。'int'， 'bool'等不是语言的实际部分，而只是实际类型的'快捷方式'或'别名'。不要使用不存在的东西!在我看来，Int16, Int32, Int64，布尔值等比'short'， 'long'， 'int'更有意义。
理解“做什么”至少和知道“如何”做一样重要，而且总是比知道解决问题的“最佳”方法重要得多。领域特定的知识对于编写好的软件通常是至关重要的。
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
在开发代码时牢记优化是一个好主意。
每当我这样说时，人们总是回答:“过早的优化是万恶之源”。
但我并不是说在调试之前进行优化。我甚至没有说优化，但当你在设计代码时，要记住这可能会成为一个瓶颈，并编写它，这样就有可能重构它的速度，而不会撕裂API。
Hugo
