这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
硬编码很好!
真的，在许多情况下更有效，更容易维护!
我看到常数放入参数文件的次数真的非常频繁 你改变了水的冰点还是光速?
对于C程序，只需将这些类型的值硬编码到头文件中，对于java程序，只需将这些值硬编码到静态类中等等。
当这些参数对你的程序行为有巨大的影响时，你真的想对每一个变化做一个回归测试，这似乎是硬编码值更自然。当东西存储在参数/属性文件中时，人们很容易认为“这不是一个程序变更，所以我不需要测试它”。
另一个好处是，它可以防止人们在参数/属性文件中混淆重要值，因为根本没有任何重要值!
其他回答
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
Python用一半的开发时间就完成了其他编程语言能做的所有事情……谷歌也是!!如果你不同意，请查看Unladen Swallow。
等等，这是事实。它还能回答这个问题吗?
意见:框架和第三方组件只能作为最后的手段。
我经常看到程序员立即选择一个框架来完成一项任务，而不学习它工作所需的底层方法。有些东西不可避免地会被打破，或者我们会发现我们没有考虑到的限制，我们会立即陷入困境，不得不重新思考系统的主要部分。只要经过仔细考虑，框架是可以使用的。
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
在1970年1月1日之前，真和假是相反的……
