这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
启用多次签出 如果我们提高了开发人员的纪律，通过自动合并源代码控制，我们将从这个设置中获得更高的效率。
其他回答
没有“放之四海而皆准”的发展方法
我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在热门博客上有许多文章都在推广“一刀切”的开发方法，所以我认为我可能只是少数。
我所见过的被吹捧为任何项目的正确方法的东西——在了解任何关于它的信息之前——像使用测试驱动开发(TDD)、领域驱动设计(DDD)、对象关系映射(ORM)、敏捷(大A)、面向对象(OO)等等，等等，包括从方法到架构到组件的一切。当然，这些都是很有市场价值的首字母缩写。
人们甚至似乎在他们的博客上贴上徽章，比如“我是测试驱动的”或类似的东西，就好像他们严格坚持单一的方法，不管项目的细节是什么，实际上是一件好事。
它不是。
选择正确的方法、体系结构和组件，等等，是应该在每个项目的基础上完成的事情，不仅取决于您正在从事的项目的类型及其独特的需求，而且还取决于与您一起工作的团队的规模和能力。
编程是如此简单，一个五岁的孩子都能做到。
编程本身并不难，这是常识。你只是在告诉计算机该做什么。你不是天才，别自以为是了。
默认情况下，所有变量/属性都应该是只读/final。
这个推理有点类似于Jon提出的类的封闭论证。程序中的一个实体应该有一个任务，而且只有一个任务。特别是，对于大多数变量和属性来说，改变值是绝对没有意义的。基本上有两个例外。
Loop variables. But then, I argue that the variable actually doesn't change value at all. Rather, it goes out of scope at the end of the loop and is re-instantiated in the next turn. Therefore, immutability would work nicely with loop variables and everyone who tries to change a loop variable's value by hand should go straight to hell. Accumulators. For example, imagine the case of summing over the values in an array, or even a list/string that accumulates some information about something else. Today, there are better means to accomplish the same goal. Functional languages have higher-order functions, Python has list comprehension and .NET has LINQ. In all these cases, there is no need for a mutable accumulator / result holder. Consider the special case of string concatenation. In many environments (.NET, Java), strings are actually immutables. Why then allow an assignment to a string variable at all? Much better to use a builder class (i.e. a StringBuilder) all along.
我意识到，今天的大多数语言并没有默认我的愿望。在我看来，由于这个原因，所有这些语言都有根本性的缺陷。如果将它们更改为默认将所有变量视为只读，并且在初始化后不允许对它们进行任何赋值，那么它们的表达性、功能和易用性将不会受到任何损失。
在我的工作场所，我一直试图引入更多的敏捷/XP开发习惯。持续设计是迄今为止我觉得阻力最大的一个。也许我不应该说“让我们召集所有的架构团队并射杀他们”……；）
当我声称代码只是我的设计的一种表达时，我经常被人大声叫嚷。我非常不喜欢看到许多开发人员在编写代码时“匆匆忙忙”地设计系统。
当其中一个牛仔从马上摔下来时所浪费的时间和精力是惊人的，而且他们遇到的问题十有八九只要前期设计工作就能解决。
我觉得现代方法没有强调设计在整个软件开发过程中的重要性。例如，当你甚至还没有审查你的设计时，对代码审查的重要性!这是疯狂。
