这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
我们在这里使用我们构建的模型-视图-控制器框架进行了大量的开发。我经常告诉我的开发人员，我们需要违反MVC设计模式的规则，以使网站运行得更快。这对开发人员来说是很难接受的，他们通常不愿意牺牲设计良好的代码。但是性能是我们构建web应用程序的首要任务，所以有时我们不得不在框架上做出让步。
例如，视图层永远不应该直接与数据库对话，对吗?但是，如果你要生成大型报告，应用程序将使用大量内存来通过模型层和控制器层传递数据。如果你有一个支持游标的数据库，它可以让应用程序更快地直接从视图层访问数据库。
性能胜过开发标准，这是我有争议的观点。
其他回答
我有争议的观点: OO编程被极大地高估了[并被视为一颗银弹]，实际上它只是工具箱中的另一个工具，没有别的!
罗布·派克写道:“数据占主导地位。如果你选择了正确的数据结构，并且组织得很好，算法几乎总是不言而喻的。数据结构，而不是算法，才是编程的核心。”
由于现在任何重要的数据都在数百万条记录中，我认为良好的数据建模是最重要的编程技能(无论是使用rdbms还是sqlite或amazon simpleDB或谷歌appengine数据存储)。
当所有的数据都存储在这样的数据存储系统中时，就不再需要花哨的搜索和排序算法了。
使用存储过程
除非您正在编写由不可重用的SQL查询组成的大型过程函数，否则请将数据库的存储过程移到版本控制中。
在1970年1月1日之前，真和假是相反的……
Never make up your mind on an issue before thoroughly considering said issue. No programming standard EVER justifies approaching an issue in a poor manner. If the standard demands a class to be written, but after careful thought, you deem a static method to be more appropriate, always go with the static method. Your own discretion is always better than even the best forward thinking of whoever wrote the standard. Standards are great if you're working in a team, but rules are meant to be broken (in good taste, of course).
