这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
你应该一直使用的唯一“最佳实践”是“动动脑子”。
太多人跳上了太多的潮流车，试图把方法、模式、框架等强加到不值得他们去做的事情上。仅仅因为某事是新的，或者因为受人尊敬的人有意见，并不意味着它适合所有人:)
编辑: 澄清一下——我认为人们不应该忽视最佳实践、有价值的意见等。只是人们不应该盲目地扑向某样东西，而不去思考为什么这个“东西”这么棒，它是否适用于我正在做的事情，它会带来什么好处/缺点?
其他回答
我也认为在源代码控制中使用二进制文件并没有什么错。如果有充分的理由的话。如果我有一个程序集，我没有源代码，并且可能不一定在每个devs机器上的相同位置，那么我通常会将它放在“二进制”目录中，并使用相对路径在项目中引用它。
相当多的人似乎认为我应该被烧死在火刑柱上，因为我甚至在同一个句子中提到了“源代码控制”和“二进制”。我甚至知道一些地方有严格的规定，说你不能添加它们。
让您的业务逻辑远离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.
扩展方法是魔鬼的工作
Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).
主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。
I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.
LINQ是这样设计的，链式方法调用是必要的，以避免奇怪和不舒服的表达式，来自LINQ的扩展方法是可以理解的，但一般来说，链式方法调用降低了可读性，并导致我们在混乱的Perl竞赛中看到的那种代码。
因此，简而言之，扩展方法是邪恶的。摆脱撒旦的枷锁，致力于自由扩展代码。
实现IDisposable的类库指南是错误的。
我不经常分享这一点，但我相信IDisposable的默认实现的指导是完全错误的。
我的问题不是Dispose的过载，然后从终结器中删除项目，而是我鄙视终结器中释放托管资源的调用。我个人认为应该抛出异常(是的，在结束器线程上抛出异常会带来很多麻烦)。
其背后的原因是，如果您是IDisposable的客户端或服务器，那么您不能简单地将对象放置在那里等待最终确定。如果您这样做了，这是一个设计/实现缺陷(取决于它是如何放置的和/或它是如何暴露的)，因为您没有意识到您应该意识到的实例的生命周期。
我认为这种类型的错误/错误是在竞争条件/资源同步的水平上。不幸的是，通过调用Dispose的重载，该错误永远不会实现。
编辑:我写了一篇关于这个主题的博客文章，如果有人感兴趣的话:
http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for-IDisposable.aspx
Web服务绝对很糟糕，也不是未来的发展方向。他们的效率低得可笑，而且他们不能保证订单交货。Web服务绝不应该在同时编写客户端和服务器的系统中使用。它们对于米老鼠混搭类型的应用程序非常有用。它们绝对不应该用于任何类型的面向连接的通信。
这种立场让我和同事们进行了一些非常热烈的讨论，因为web服务是一个非常热门的话题。任何强制使用web服务的项目都是注定要失败的，因为它显然已经从管理层那里得到了荒谬的要求。
