这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
对自己有争议，因为有些事情还是不说为好，这样才不会被别人说成太自我。然而，它是:
如果要这样，从我开始
其他回答
这种最佳实践是一种危险，因为它们要求我们用口号代替思考。
创建类似于带有疯牛病的椒盐卷饼的UML图的能力实际上并不是一种有用的软件开发技能。
图代码的全部意义在于可视化连接，看到设计的形状。但是一旦你通过了一个相当低的复杂水平，想象就太多了，无法在精神上处理。只有在坚持使用直线的情况下，图形化地建立连接才比较简单，这通常会使图表比沿着基本方向巧妙地分组和路由连接更难阅读。
仅在广泛的交流目的下使用图表，并且仅当它们被理解为谎言时使用。
根据我得到的大量反馈，我最具争议的观点显然是，程序员并不总是读他们声称读过的书。这紧跟着我的观点，一个受过正规教育的程序员比一个自学成才的程序员更好(但不一定比另一个自学成才的程序员更好)。
编写小方法。程序员似乎喜欢编写冗长的方法，在这些方法中他们可以做多种不同的事情。
我认为应该在任何可以命名的地方创建方法。
意见:框架和第三方组件只能作为最后的手段。
我经常看到程序员立即选择一个框架来完成一项任务，而不学习它工作所需的底层方法。有些东西不可避免地会被打破，或者我们会发现我们没有考虑到的限制，我们会立即陷入困境，不得不重新思考系统的主要部分。只要经过仔细考虑，框架是可以使用的。
