这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
.．.“澄清想法”不应该是开发者的唯一责任……是的，XKCD让我用了那个特定的短语…
我们经常会收到一些项目，这些项目都是在伪元类型特定的“代码”中指定的，如果你愿意这样称呼它的话。经常有产品经理为一个项目制定初始需求，并执行接近0%的基本逻辑验证。
我并不是说技术方法不应该由架构师制定，或者具体的实现不应该是开发人员的责任，而是说它应该是产品经理的需求，以确保他们的需求在逻辑上是可行的。
就我个人而言，我参与过太多“简单”的项目，这些项目在这里或那里遇到了一些范围渐变，然后遇到了与之前的需求相矛盾的“小”更改或功能添加——无论是含蓄的还是明确的。在这种情况下，要求做出近乎不可能的改变的人很容易对开发人员无法实现他们的梦想感到愤怒。
其他回答
观点:大多数代码都很糟糕，因为这是程序员想要的。
间接地，我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。
If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.
复杂，复杂，丑陋的东西只会变得更糟，更不稳定。如果我们正在建造一些实体的东西，地球上的每个人都会说我们的东西是多么丑陋和糟糕，但由于它或多或少被虚拟隐藏起来，我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)
但可悲的是，这一切中有争议的部分是，绝对没有理由这样做，除了历史上的文化倾向于更多的自由和更少的组织，所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话，但它是一个笑话，因为这是程序员想要的(但永远不会承认这是真的，“管理层的阴谋”对大多数人来说是一个更好的理由)。
我们还会搬起石头砸自己的脚多久，才会幡然醒悟，意识到我们才是握着枪、指着枪、扣动扳机的人?
保罗。
源代码控制:除了SourceSafe
另外:排他锁定是邪恶的。
我曾经在某个地方工作过，他们认为排他锁意味着您可以保证当您签入时，人们不会覆盖其他人的更改。问题在于，为了完成任何工作，如果文件被锁定，开发人员只会在有机会时将本地文件更改为可写，并合并(或覆盖)版本的源代码控制。
让您的业务逻辑远离DB。或者至少，保持它非常精简。让DB做它应该做的事情。让代码做它应该做的事情。时期。
If you're a one man show (basically, arrogant & egotistical, not listening to the wisdom of others just because you're in control), do as you wish. I don't believe you're that way since you're asking to begin with. But I've met a few when it comes to this subject and felt the need to specify. If you work with DBA's but do your own DB work, keep clearly defined partitions between your business objects, the gateway between them and the DB, and the DB itself. If you work with DBA's and aren't allowed to do your DB work (either by policy or because they're premadonnas), you're very close to being a fool placing your reliance on them to get anything done by putting code-dependant business logic in your DB entities (sprocs, functions, etc.). If you're a DBA, make developers keep their DB entities clean & lean.
编码不是打字
编写代码需要时间。大多数时候，在编辑器窗口中，您只是查看代码，而不是实际输入。虽然不是经常，但你经常会删除你所写的内容。或者从一个地方搬到另一个地方。或重命名。
如果你长时间敲击键盘，那你一定做错了什么。
推论:每天写的代码行数并不是一个程序员生产力的线性衡量标准，一天写100行的程序员很可能比一天写20行的程序员更好，但一天写5000行的程序员肯定是坏程序员
实现IDisposable的类库指南是错误的。
我不经常分享这一点，但我相信IDisposable的默认实现的指导是完全错误的。
我的问题不是Dispose的过载，然后从终结器中删除项目，而是我鄙视终结器中释放托管资源的调用。我个人认为应该抛出异常(是的，在结束器线程上抛出异常会带来很多麻烦)。
其背后的原因是，如果您是IDisposable的客户端或服务器，那么您不能简单地将对象放置在那里等待最终确定。如果您这样做了，这是一个设计/实现缺陷(取决于它是如何放置的和/或它是如何暴露的)，因为您没有意识到您应该意识到的实例的生命周期。
我认为这种类型的错误/错误是在竞争条件/资源同步的水平上。不幸的是，通过调用Dispose的重载，该错误永远不会实现。
编辑:我写了一篇关于这个主题的博客文章，如果有人感兴趣的话:
http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for-IDisposable.aspx
