这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
用户不是傻瓜——你才是。
很多次我听到开发者说“某某人是个白痴”，我的回答通常是“他可能是个白痴，但你允许他这么做。”
其他回答
不断测试
您必须编写测试，并且必须首先编写它们。编写测试会改变编写代码的方式。它会让你思考你想要它实际做什么，然后再开始写一些东西，它能做所有事情，除了你想要它做的。
它也给你目标。看着你的测试变绿会让你有额外的信心，因为你完成了一些事情。
它还为您为边缘情况编写测试提供了基础。由于您一开始就针对测试编写代码，因此您的代码中可能有一些用于测试的钩子。
没有理由不测试你的代码。如果你不这样做，那你只是懒惰。我还认为您应该先进行测试，因为这样做的好处超过了编写代码所花费的额外时间。
一幅画不如一千个词。
有些图片可能胜过千言万语。大多数都不是。这句陈词滥调大多是不真实的，是许多懒惰的经理的可悲借口，他们不想仔细阅读创建的报告和文档，说“我需要你在图表中展示给我看”。
我妻子学的是语言学专业，她看到了一些关于图片和标志的令人着迷的证据:它们不能打破语言和文化的障碍，它们通常不能像正确的文本那样传达那么多的信息，它们根本不能取代真正的交流。
特别是，如果线条未被标记且无法解释，并且/或如果每一行都有不同的含义而不是表示相同的关系(除非以某种方式彼此区分)，那么与线条连接的标记气泡是无用的。如果你的线条有时表示关系，有时表示动作，有时表示时间的流逝，你就真的完蛋了。
每个优秀的程序员都知道你使用的工具适合手头的工作，对吗?并不是所有的系统都最好用图片来说明和记录。图形化规范语言可以自动转换为可证明正确的可执行代码或任何东西，这是一个了不起的想法，如果这样的东西存在的话。在适当的时候使用它们，而不是在阳光下的所有事情上。实体-关系图很棒。但并不是所有的事情都可以用一张图片来概括。
注:一张桌子可能值同等重量的金子。但是表格和图片不是一回事。同样，一篇精心设计的短散文段落可能更适合手头的工作。
观点:大多数代码都很糟糕，因为这是程序员想要的。
间接地，我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。
If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.
复杂，复杂，丑陋的东西只会变得更糟，更不稳定。如果我们正在建造一些实体的东西，地球上的每个人都会说我们的东西是多么丑陋和糟糕，但由于它或多或少被虚拟隐藏起来，我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)
但可悲的是，这一切中有争议的部分是，绝对没有理由这样做，除了历史上的文化倾向于更多的自由和更少的组织，所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话，但它是一个笑话，因为这是程序员想要的(但永远不会承认这是真的，“管理层的阴谋”对大多数人来说是一个更好的理由)。
我们还会搬起石头砸自己的脚多久，才会幡然醒悟，意识到我们才是握着枪、指着枪、扣动扳机的人?
保罗。
大于运算符(>，>=)应该被弃用
我试着用“小于”而不是“大于”的偏好编码了一段时间，它卡住了!我不想回去，事实上，我觉得在这种情况下，每个人都应该按照我的方式去做。
考虑常见的数学“范围”符号:0 <= i < 10
这很容易在代码中近似，你已经习惯了在中间重复变量并用&&连接:
if (0 <= i && i < 10)
return true;
else
return false;
一旦你习惯了这种模式，你就再也不会觉得愚蠢了
if ( ! (i < 0 || i >= 9))
return true;
同样的方法。
长序列的关系变得更容易处理，因为操作数倾向于非递减顺序。
此外，操作符<的优先级被铭记在c++标准中。在某些情况下，operator=是根据it来定义的!(a<b || b<a))
源文件太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出来谷歌说的是"搜索，不排序"吗?那么，为什么同样的哲学不能应用于编程语言呢?
