这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
整天在Stackoverflow上回答问题的程序员可能并没有在做他们应该做的工作。
其他回答
小代码总是更好，但是复杂?:而不是if-else让我意识到有时大代码更可读。
除非你能解释为什么需要继承，否则不要使用它。
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
默认情况下，数组应该基于1，而不是基于0。系统实现语言不一定是这样，但是像Java这样的语言吸收了更多C语言的奇怪之处。“元素1”应该是第一个元素，而不是第二个，以避免混淆。
计算机科学不是软件开发。毕竟，你不会雇佣一个只学过物理的工程师。
尽可能多地学习数学。您不会使用大部分的知识，但是您需要能够以这种方式思考才能擅长软件。
目前标准化的唯一最好的编程语言是Common Lisp，尽管它很冗长并且有从零开始的数组。这很大程度上是因为它被设计成一种方式 来写计算，而不是抽象的冯·诺依曼机器。
至少90%的对编程语言的比较批评可以归结为“语言A有C特性，而我不知道如何在语言B中实现C或类似的功能，所以语言A更好。”
“最佳实践”是我所见过的“平庸”最令人印象深刻的拼写方式。
Never make up your mind on an issue before thoroughly considering said issue. No programming standard EVER justifies approaching an issue in a poor manner. If the standard demands a class to be written, but after careful thought, you deem a static method to be more appropriate, always go with the static method. Your own discretion is always better than even the best forward thinking of whoever wrote the standard. Standards are great if you're working in a team, but rules are meant to be broken (in good taste, of course).
