这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
可读性是代码最重要的方面。
甚至比正确性更重要。如果它是可读的，就很容易修复。它也很容易优化，容易改变，容易理解。希望其他开发者也能从中学到一些东西。
其他回答
规模很重要!修饰你的代码，让它看起来更大。
编写大量的规格说明是徒劳的。 编写正确的程序是相当困难的，但是编译器、调试器、单元测试器、测试器等使检测和消除大多数错误成为可能。另一方面，当你像一个程序(例如，伪代码，UML)那样编写具有相当详细级别的规范时，你主要是靠自己。如果您有一个工具可以帮助您正确地处理语法，那么您应该感到幸运。
广泛的规范很可能充满bug。 编写人员在第一次尝试中得到正确答案的可能性，与一个类似的大型程序在没有经过测试的情况下没有错误的可能性是相同的。同行评审可以消除一些错误，就像代码评审一样。
小代码总是更好，但是复杂?:而不是if-else让我意识到有时大代码更可读。
宏，预处理器指令和注释是邪恶的。
每个文件只使用一种语法和语言!
//不适用于Make文件或插入真实代码的编辑器宏。
程序员需要与客户交流
一些程序员认为，他们不需要成为与客户交谈的人。对于你的公司来说，这是一种肯定的方式，可以写出一些绝对出色的东西，没有人知道它是用来做什么的，也没有人知道它是如何被使用的。
你不能指望产品经理和业务分析师做所有的决定。事实上，程序员应该在创建模块或特性的1000个(通常是小的)决策中做出990个，否则产品将永远不会发布!所以确保你的决定是明智的。了解你的客户，与他们一起工作，观察他们使用你的软件。
如果你想写出最好的代码，你希望人们使用它。对你的用户群感兴趣，向那些“愚蠢的傻瓜”学习。别害怕，他们会因此爱上你的。
