这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
递归很有趣。
是的，我知道这可能是对堆栈空间的无效使用，诸如此类。但有时候递归算法比迭代算法更简洁。当我能把递归函数藏在某个地方时，我总是有点高兴。
其他回答
方法/函数参数的先决条件应该是语言的一部分，而不是程序员总是检查它。
我有争议的观点:面向对象编程绝对是软件工程领域发生过的最糟糕的事情。
面向对象编程的主要问题是完全缺乏一个每个人都能认同的严格定义。这很容易导致实现中存在逻辑漏洞，或者像Java这样的语言坚持这种关于OOP含义的奇怪的宗教教条，同时迫使程序员做所有这些扭曲和“设计模式”，只是为了绕过特定OOP系统的限制。
因此，OOP欺骗程序员，让他们认为他们正在获得这些巨大的生产力收益，OOP在某种程度上是一种“自然”的思考方式，同时迫使程序员输入大量不必要的样板文件。
然后，由于没有人知道OOP的真正含义，我们浪费了大量的时间在争论语言X或Y是否“真正的面向对象”，什么奇怪的语言特性对于一种语言被认为是“真正的面向对象”是绝对“必要的”。
与其要求这种语言或那种语言是“真正的面向对象的”，我们应该看看实验显示了什么语言特性，以实际提高生产力，而不是试图强迫它成为某种想象中的理想语言，或者强迫我们的程序符合某种“真正面向对象的程序”的柏拉图式理想。
与其坚持我们的程序符合“真正面向对象”的柏拉图式理想，不如我们专注于坚持良好的工程原则，使我们的代码易于阅读和理解，并使用一种语言的高效和有用的特性，而不管它们是否足够“面向对象”。
最新的设计模式往往是骗人的。正如之前在这个问题中所说的，过度使用设计模式对设计的危害远大于帮助。
如果我再听到一个人说“每个人都应该使用IOC”(或类似的废话)，我想我将被迫找到他们，并告诉他们他们方法的错误。
每当您向外界公开一个可变类时，您都应该提供事件来观察它的变化。额外的努力也可能说服您最终使其不可更改。
你应该一直使用的唯一“最佳实践”是“动动脑子”。
太多人跳上了太多的潮流车，试图把方法、模式、框架等强加到不值得他们去做的事情上。仅仅因为某事是新的，或者因为受人尊敬的人有意见，并不意味着它适合所有人:)
编辑: 澄清一下——我认为人们不应该忽视最佳实践、有价值的意见等。只是人们不应该盲目地扑向某样东西，而不去思考为什么这个“东西”这么棒，它是否适用于我正在做的事情，它会带来什么好处/缺点?
