这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
现代c++是一门美丽的语言。
我说出来了。很多人真的很讨厌c++，但说实话，我发现现代c++与STL/Boost风格的编程在大多数时候是一种非常有表现力、优雅和令人难以置信的高效语言。
我认为大多数讨厌c++的人都是基于使用OO的糟糕经历。c++在面向对象方面做得不是很好，因为多态性通常依赖于堆分配对象，而且c++没有自动垃圾收集。
但c++真正的亮点在于泛型库和函数式编程技术，这使得构建难以置信的大型、高度可维护的系统成为可能。很多人说c++试图做所有事情，但最终什么都做不好。我可能同意它在面向对象方面不如其他语言，但它在泛型编程和函数编程方面比任何其他主流的基于c的语言都要好。(c++ 0x只会进一步强调这一事实。)
我也很欣赏c++如何让我在必要时获得底层，并提供对操作系统的完全访问。
加上RAII。认真对待。当我用其他c语言编程时，我真的很想念析构函数。(不，垃圾回收不会使析构函数无用。)
其他回答
单身人士并不邪恶
There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Addtionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.
MS Access*是一个真正的开发工具，专业程序员可以毫无羞耻地使用它
仅仅因为某个平台吸引了自认为是程序员的黑客和秘书，就不应该玷污这个平台本身。每个平台都有其优点和缺点。
那些抱怨某些平台或工具或将其贬低为“玩具”的程序员更有可能对自己的手艺知之甚少，而不是他们的自我意识所说服的那样。对我来说，听到一个程序员抨击任何他们自己没有广泛使用过的环境是一种过度自信的表现。
*在这里插入任何恶意工具(VB, PHP等)。
观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。
绝大多数软件不是关于数据的，而是关于我们试图为客户解决的业务问题。它是关于一个问题域的，涉及对象、规则、流程、案例和关系。
当我们从数据开始设计，并根据数据和数据之间的关系(表、外键和x-to-x关系)对系统的其余部分建模时，我们将整个应用程序限制为如何在数据库中存储数据和如何从数据库中检索数据。此外，我们将数据库体系结构公开给软件。
数据库模式是一个实现细节。我们应该可以自由地改变它，而不需要对我们的软件设计进行任何显著的改变。业务层不应该知道表是如何设置的，或者是从视图中提取还是从表中提取，或者是从动态SQL或存储过程中获取表。这种类型的代码永远不应该出现在表示层中。
软件是用来解决业务问题的。我们要处理用户、汽车、帐户、余额、平均值、摘要、转账、动物、消息、包裹、购物车、订单和其他各种真实的有形对象，以及我们可以对它们执行的操作。我们需要根据需要保存、加载、更新、查找和删除这些项。有时候，我们必须以特殊的方式来做这些事情。
But there's no real compelling reason that we should take the work that should be done in the database and move it away from the data and put it in the source code, potentially on a separate machine (introducing network traffic and degrading performance). Doing so means turning our backs on the decades of work that has already been done to improve the performance of stored procedures and functions built into databases. The argument that stored procedures introduce "yet another API" to be manged is specious: of course it does; that API is a facade that shields you from the database schema, including the intricate details of primary and foreign keys, transactions, cursors, and so on, and it prevents you from having to splice SQL together in your source code.
把马放回马车前面。思考问题领域，并围绕它设计解决方案。然后，从问题域导出数据。
如果你知道如何编程，你就不适合在表单上放置按钮
这有足够的争议吗?；）
不管我们多么努力，我们几乎不可能对53岁的Doris产生适当的同情，她必须使用我们的订单输入软件。我们根本无法掌握她想象的计算机内部正在发生的事情的心智模式，因为我们不需要想象:我们知道正在发生什么，或者有一个非常好的想法。
交互设计应该由非程序员来完成。当然，这永远不会发生。相反，我对此很高兴;我喜欢UI设计，尽管内心深处我知道我并不适合它。
欲了解更多信息，请阅读《囚犯们在管理精神病院》这本书。请注意，这本书让我心烦意乱，很无礼;如果你是一个关心用户体验的开发人员，这是一篇很难读懂的文章。
编写小方法。程序员似乎喜欢编写冗长的方法，在这些方法中他们可以做多种不同的事情。
我认为应该在任何可以命名的地方创建方法。
