这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
信不信由你，我认为在面向对象语言中，操作类数据的大部分(业务逻辑)代码应该在类本身中，这在我的团队中是异端。
其他回答
函数式编程并不比命令式编程更直观或更容易学习。
函数式编程有很多优点，但我经常听到函数式程序员说，对于没有编程经验的人来说，理解函数式编程比理解命令式编程更容易。据我所知，情况恰恰相反，人们发现琐碎的问题很难解决，因为他们不知道如何管理和重用他们的临时结果，当你在一个没有状态的世界结束时。
观点:开发者应该测试自己的代码
我曾经见过太多的垃圾交付给测试，但实际上并没有修复问题中的bug，导致了沟通开销，并助长了不负责任的实践。
我认为使用goto语句是很好的，如果你以一种理智的方式使用它们(以及一种理智的编程语言)。它们通常可以使您的代码更容易阅读，并且不会强迫您使用一些扭曲的逻辑来完成一件简单的事情。
牛仔程序员做得更多。
我一生都在创业的氛围中度过。如果没有牛仔编码员，我们将浪费无尽的周期来确保事情做得“正确”。
正如我们所知，预测所有问题基本上是不可能的。牛仔编码员会迎头撞上这些问题，并被迫比那些试图预见所有问题的人更快地解决它们。
不过，如果你是牛仔编码，你最好在其他人维护意大利面之前重构它。,)我所知道的最好的方法是使用持续重构。他们完成了大量的工作，不浪费时间试图预测未来，并通过重构成为可维护的代码。
过程总是阻碍一个优秀的牛仔，不管它有多敏捷。
有很多糟糕的教学。
当Joel说大脑中有一部分是用来理解指针的，而有些人生来就没有指针时，我们开发人员就会沾沾自喜。我们许多人在这里讨论和热衷的话题都很深奥，但有时这只是因为我们把它们弄得如此深奥。
