这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
在开发代码时牢记优化是一个好主意。
每当我这样说时，人们总是回答:“过早的优化是万恶之源”。
但我并不是说在调试之前进行优化。我甚至没有说优化，但当你在设计代码时，要记住这可能会成为一个瓶颈，并编写它，这样就有可能重构它的速度，而不会撕裂API。
Hugo
其他回答
我不认为任何与优化相关的问题都应该充斥着被错误引用的“过早优化是万恶之源”的口号，因为被优化到混乱的代码才是编码的乐趣所在
不是工具的问题，是你的问题
每当开发人员尝试做一些新的事情，比如做UML图，任何类型的图表，项目管理，他们首先寻找完美的工具来解决问题。在无休止的寻找后，他们发现没有合适的工具，他们的动机就会枯竭。剩下的就是对缺乏可用软件的抱怨。这是一种洞察力，在没有软件的情况下，要组织的计划夭折了。
好吧，只有你自己在处理组织问题。如果你习惯了组织，你可以使用或不使用软件来完成(大多数人都不需要软件)。如果你不习惯组织，没有人能帮助你。
所以“没有合适的软件”只是没有组织的最简单的借口。
如果你需要阅读说明书，说明这个软件还不够好。
简单明了:-)
人们抱怨将“goto”从语言中移除。我碰巧认为任何类型的条件跳转都被高估了，而“if”“while”“switch”和通用的“for”循环也被高估了，应该非常谨慎地使用。
每次进行比较和条件跳转时，都会增加一点点复杂性，一旦调用堆栈达到几百个条目，这种复杂性就会迅速增加。
我的第一选择是避免条件，但如果不实用，我的下一个选择是在构造函数或工厂方法中保留条件复杂性。
显然，这对于许多项目和算法(如控制流循环)来说并不实际，但这是我喜欢推动的事情。
瑞克
“评论是谎言”
注释不能运行，而且很容易被忽略。最好是用清晰的、由单元测试说明的重构代码来表达意图。(当然是编写TDD的单元测试…)
我们不写注释，因为它们很冗长，而且模糊了代码中真正发生的事情。如果你觉得需要注释——找出代码中不清楚的地方，然后重构/编写更清晰的测试，直到不需要注释……
．.． 我从极限编程中学到的东西(当然，假设你已经建立了清理代码的团队规范……)
