这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
代码生成很糟糕
我讨厌那些要求你使用代码生成(或复制&粘贴)来处理简单事情的语言，比如JavaBeans的getter和setter。
c#的AutoProperties是朝着正确方向迈出的一步，但是对于具有字段、属性和构造函数参数的dto来说，你仍然需要大量的冗余。
其他回答
观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。
绝大多数软件不是关于数据的，而是关于我们试图为客户解决的业务问题。它是关于一个问题域的，涉及对象、规则、流程、案例和关系。
当我们从数据开始设计，并根据数据和数据之间的关系(表、外键和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.
把马放回马车前面。思考问题领域，并围绕它设计解决方案。然后，从问题域导出数据。
分页从来不是用户想要的
If you start having the discussion about where to do pagination, in the database, in the business logic, on the client, etc. then you are asking the wrong question. If your app is giving back more data than the user needs, figure out a way for the user to narrow down what they need based on real criteria, not arbitrary sized chunks. And if the user really does want all those results, then give them all the results. Who are you helping by giving back 20 at a time? The server? Is that more important than your user?
[编辑:基于评论的澄清]
作为一个真实世界的例子，让我们看看这个Stack Overflow问题。假设我有一个有争议的编程观点。在我发帖之前，我想看看是否已经有了一个解决相同观点的答案，这样我就可以给它投票了。我唯一的选择就是点击每一页的答案。
我更喜欢以下选择之一:
请允许我搜索答案(这是一种根据实际标准缩小我需要的范围的方法)。 允许我看到所有的答案，这样我就可以使用浏览器的“查找”选项(给我所有的结果)。
如果我只是想找到以前读过的答案，但再也找不到了，也可以这样做。我不知道它是什么时候发布的，也不知道它有多少选票，所以排序选项没有帮助。即使我找到了，我仍然需要玩猜谜游戏来找到正确的结果页面。事实上，答案是有页码的，我可以直接点击进入十几个页面中的一个，这一点帮助都没有。
-- bmb
XHTML是邪恶的。编写HTML
无论如何，您都必须将MIME类型设置为text/html，所以为什么要欺骗自己相信您实际上是在编写XML呢?无论谁要下载你的页面，他都会相信这是HTML，所以把它做成HTML。
有了这些，不要关闭你的<li>，这是没有必要的。不要关闭html标签，文件已经结束了。它是有效的HTML，可以被完美地解析。
它将创建更可读、更少的样板代码，并且不会丢失任何东西。HTML解析器工作得很好!
当你完成后，再转向HTML5。这样更好。
如果您的文本编辑器不能很好地完成代码，那么您就是在浪费每个人的时间。
Quickly remembering thousands of argument lists, spellings, and return values (not to mention class structures and similarly complex organizational patterns) is a task computers are good at and people (comparatively) are not. I buy wholeheartedly that slowing yourself down a bit and avoiding the gadget/feature cult is a great way to increase efficiency and avoid bugs, but there is simply no benefit to spending 30 seconds hunting unnecessarily through sourcecode or docs when you could spend nil... especially if you just need a spelling (which is more often than we like to admit).
当然，如果没有为您的语言提供这种功能的编辑器，或者任务简单到足以在加载更重的编辑器所需的时间内完成，那么没有人会告诉您Eclipse和90个插件是正确的工具。但是请不要告诉我，像1999年那样使用H-J-K-L的能力真的比每次需要方法签名时按escape键节省了更多时间……即使你觉得这样做不那么“黑客”了。
想法吗?
意见:不应该有任何编译器警告，只有错误。你应该总是使用-Werror编译你的代码。
原因:要么编译器认为这是一个应该被纠正的错误，要么它不需要修复，在这种情况下编译器应该直接关闭。
