这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
一幅画不如一千个词。
有些图片可能胜过千言万语。大多数都不是。这句陈词滥调大多是不真实的，是许多懒惰的经理的可悲借口，他们不想仔细阅读创建的报告和文档，说“我需要你在图表中展示给我看”。
我妻子学的是语言学专业，她看到了一些关于图片和标志的令人着迷的证据:它们不能打破语言和文化的障碍，它们通常不能像正确的文本那样传达那么多的信息，它们根本不能取代真正的交流。
特别是，如果线条未被标记且无法解释，并且/或如果每一行都有不同的含义而不是表示相同的关系(除非以某种方式彼此区分)，那么与线条连接的标记气泡是无用的。如果你的线条有时表示关系，有时表示动作，有时表示时间的流逝，你就真的完蛋了。
每个优秀的程序员都知道你使用的工具适合手头的工作，对吗?并不是所有的系统都最好用图片来说明和记录。图形化规范语言可以自动转换为可证明正确的可执行代码或任何东西，这是一个了不起的想法，如果这样的东西存在的话。在适当的时候使用它们，而不是在阳光下的所有事情上。实体-关系图很棒。但并不是所有的事情都可以用一张图片来概括。
注:一张桌子可能值同等重量的金子。但是表格和图片不是一回事。同样，一篇精心设计的短散文段落可能更适合手头的工作。
其他回答
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).
从长远来看，开源软件的成本更高
对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。
当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。
精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。
源文件太20世纪了。
在函数/方法的主体中，将过程逻辑表示为线性文本是有意义的。即使逻辑不是严格的线性，我们也有良好的编程结构(循环、if语句等)，允许我们使用线性文本清晰地表示非线性操作。
But there is no reason that I should be required to divide my classes among distinct files or sort my functions/methods/fields/properties/etc in a particular order within those files. Why can't we just throw all those things within a big database file and let the IDE take care of sorting everything dynamically? If I want to sort my members by name then I'll click the member header on the members table. If I want to sort them by accessibility then I'll click the accessibility header. If I want to view my classes as an inheritence tree, then I'll click the button to do that.
Perhaps classes and members could be viewed spatially, as if they were some sort of entities within a virtual world. If the programmer desired, the IDE could automatically position classes & members that use each other near each other so that they're easy to find. Imaging being able to zoom in and out of this virtual world. Zoom all the way out and you can namespace galaxies with little class planets in them. Zoom in to a namespace and you can see class planets with method continents and islands and inner classes as orbitting moons. Zoom in to a method, and you see... the source code for that method.
基本上，我的观点是，在现代语言中，不管你把你的类放在什么文件中，或者你定义一个类的成员的顺序是什么，那么为什么我们仍然被迫使用这些古老的实践呢?还记得Gmail出来谷歌说的是"搜索，不排序"吗?那么，为什么同样的哲学不能应用于编程语言呢?
人们应该注释他们的代码?这似乎在这里很有争议。
代码只告诉我它实际做什么;这不是它应该做的
当我看到一个函数计算澳大利亚债券期货的点价值时，我想看到一些注释，表明编码器认为计算应该是什么!
UML图被高度高估了
当然有一些有用的图，例如复合模式的类图，但是许多UML图是绝对没有价值的。
