这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
匿名函数很糟糕。
我正在自学jQuery，虽然它是一种优雅且非常有用的技术，但大多数人似乎都将其视为最大化匿名函数用户的某种竞争。
函数和过程命名(以及变量命名)是我们在编程中所拥有的最强大的表达能力。将函数作为数据传递是一项伟大的技术，但使它们匿名并因此非自文档化是一个错误。这样就失去了表达代码含义的机会。
其他回答
如果我有争议的话，我不得不说乔恩·斯基特并不是万能的。
关系数据库是在浪费时间。改用对象数据库!
关系数据库供应商试图欺骗我们，让我们相信世界上唯一可扩展的、持久的和安全的存储就是关系数据库。我是一个认证的DBA。你是否曾经花了几个小时试图优化一个查询，却不知道哪里出了问题?关系数据库不允许您在需要时创建自己的搜索路径。你把应用速度的控制权拱手让给了素未谋面的人，他们并不像你想象的那么聪明。
当然，有时在维护良好的数据库中，他们会为复杂的查询提供快速答案。但你为此付出的代价太高了!每次要读取数据项时，都必须选择编写原始SQL，这是很危险的。或者使用Object关系映射器，这会增加更多的复杂性和超出你控制的事情。
更重要的是，你被禁止提出智能搜索算法，因为每次该死的往返数据库花费你大约11毫秒。这太过分了。想象一下，您知道这个超级图算法，它将回答一个特定的问题，这个问题甚至可能无法用SQL表达!，在适当的时候。但是，即使您的算法是线性的，而有趣的算法不是线性的，也不要将它与关系数据库结合起来，因为枚举一个大表将花费您数小时!
将其与SandstoneDb或Gemstone for Smalltalk进行比较!如果你喜欢Java，试试db4o吧。
因此，我的建议是:使用对象- db。当然，它们并不完美，有些查询速度会比较慢。但是你会惊讶的发现很多人会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您确实需要某个查询的速度，对象数据库有您应该信任的查询优化器:您的大脑。
“不要从构造函数调用虚方法”。这只是有时PITA，但只是因为在c#中，我不能决定在构造函数中的哪个点调用基类的构造函数。为什么不呢?.NET框架允许它，那么c#有什么好的理由不允许它呢?
该死的!
意识到有时候足够好就是足够好，这是你作为程序员价值的一大飞跃。
请注意，当我说“足够好”时，我的意思是“足够好”，而不是碰巧有用的垃圾。但话又说回来，当你时间紧迫的时候，“一些碰巧有用的垃圾”可能被认为是“足够好的”。
Requirements analysis, specification, design, and documentation will almost never fit into a "template." You are 100% of the time better off by starting with a blank document and beginning to type with a view of "I will explain this in such a way that if I were dead and someone else read this document, they would know everything that I know and see and understand now" and then organizing from there, letting section headings and such develop naturally and fit the task you are specifying, rather than being constrained to some business or school's idea of what your document should look like. If you have to do a diagram, rather than using somebody's formal and incomprehensible system, you're often better off just drawing a diagram that makes sense, with a clear legend, which actually specifies the system you are trying to specify and communicates the information that the developer on the other end (often you, after a few years) needs to receive.
[如果有必要，一旦您编写了真正的文档，您通常可以把它塞进组织强加给您的任何模板中。不过，你可能会发现自己不得不添加章节标题和重复的材料。
The only time templates for these kinds of documents make sense is when you have a large number of tasks which are very similar in nature, differing only in details. "Write a program to allow single-use remote login access through this modem bank, driving the terminal connection nexus with C-Kermit," "Produce a historical trend and forecast report for capacity usage," "Use this library to give all reports the ability to be faxed," "Fix this code for the year 2000 problem," and "Add database triggers to this table to populate a software product provided for us by a third-party vendor" can not all be described by the same template, no matter what people may think. And for the record, the requirements and design diagramming techniques that my college classes attempted to teach me and my classmates could not be used to specify a simple calculator program (and everyone knew it).
