这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
Python用一半的开发时间就完成了其他编程语言能做的所有事情……谷歌也是!!如果你不同意，请查看Unladen Swallow。
等等，这是事实。它还能回答这个问题吗?
其他回答
软件开发是一门艺术。
记录器配置是浪费时间。如果这意味着学习一种新的语法，尤其是一种无声地失败的语法，为什么要有它们呢?不要误解我，我喜欢好的伐木。我喜欢日志记录器的继承和向日志记录器的处理程序添加格式化程序。但是为什么要在配置文件中进行呢?
您希望在不重新编译的情况下对日志代码进行更改吗?为什么?如果您将日志代码放在单独的类、文件中，会有什么不同呢?
您是否希望将可配置的日志与您的产品一起分发给客户端?这不是提供了太多信息吗?
最令人沮丧的是，用流行语言编写的流行实用程序往往会按照该语言指定的格式编写良好的api。编写一个Java日志实用程序，我知道您已经生成了javadocs，我知道如何导航。为您的日志记录器配置编写一种特定于域的语言，我们有什么?也许有文件，但到底哪里去了?你来决定怎么组织，我对你的思路不感兴趣。
管理者无所不知
根据我的经验，经理通常不是通过了解代码来达到这个目的的。不管你怎么跟他们说，它太长了，不对或者太贵了。
还有一个是继第一个之后的:
没有时间把事情做对，但总有时间再做一遍
一位很好的工程师朋友曾经说过，他很生气地描述了这样一种情况:管理层把他的估计减半了，从他那里得到了一个半途而废的版本，然后给了他两倍的时间来返工，因为它失败了。在商业软件世界中，这是一件相当常见的事情。
今天在尝试配置一个只有web接口的路由器时，我想到了一个问题:
网页界面是为傻瓜准备的
上一个固件版本的CLI非常好。这个版本有一个web界面，试图从无知的IT机器人那里隐藏所有网络的复杂性，甚至不能得到正确的vlan。
对象不应该处于无效状态
不幸的是，许多ORM框架要求所有实体类都使用零参数构造函数，使用setter填充成员变量。在这些情况下，很难知道为了构造一个有效的对象必须调用哪些setter。
MyClass c = new MyClass(); // Object in invalid state. Doesn't have an ID.
c.setId(12345); // Now object is valid.
在我看来，一个对象不可能发现自己处于无效状态，类的API应该在每次方法调用后主动强制它的类不变量。
构造函数和突变方法应该原子地将对象从一种有效状态转换为另一种有效状态。这个好多了:
MyClass c = new MyClass(12345); // Object starts out valid. Stays valid.
作为一些库的使用者，在尝试使用一个对象之前跟踪是否调用了所有正确的setter是一件非常痛苦的事情，因为文档通常没有提供关于类契约的线索。
当涉及到软件设计和开发时，设计模式是一种浪费时间的行为。
不要误解我的意思，设计模式是有用的，但主要是作为一种交流载体。它们可以非常简洁地表达复杂的思想:工厂、单例、迭代器……
但它们不应该作为一种开发方法。开发人员经常使用一系列基于设计模式的类来构建他们的代码，而在可读性和性能方面，更简洁的设计会更好。所有这些都带有一种幻想，即单个类可以在它们的域之外被重用。如果一个类不是为重用而设计的，或者不是接口的一部分，那么它就是一个实现细节。
设计模式应该被用来为组织特性命名，而不是用来规定必须编写代码的方式。
(这本来是有争议的，记得吗?)
