这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
软件开发人员、编码员、程序员、架构师之间没有区别……
我在酵母行业工作过10多种，但仍然觉得试图区分这些“角色”是绝对愚蠢的。你写代码?你是开发人员。你整天都在画漂亮的UML图。你是个…嗯. .我不知道你是谁，你可能只是想给别人留下好印象。(是的，我知道UML)。
其他回答
Linq2Sql并没有那么糟糕
我看到过很多诋毁Linq2Sql的帖子。我知道这并不完美，但什么才是完美的?
就我个人而言，我认为它有它的缺点，但总的来说，它可以很好地用于原型设计，或开发中小型应用程序。当我考虑到它为我从编写枯燥的DAL代码中节省了多少时间时，我不能抱怨，特别是考虑到我们不久前拥有的替代方案。
每当您向外界公开一个可变类时，您都应该提供事件来观察它的变化。额外的努力也可能说服您最终使其不可更改。
一旦发现缺陷就改正。不仅仅是“严重程度1”的缺陷;所有的缺陷。
建立一种部署机制，使用户可以立即使用应用程序更新，但允许他们选择何时接受这些更新。与用户建立直接的沟通机制，使他们能够报告缺陷，将他们的经验与更新联系起来，并提出改进建议。
With aggressive testing, many defects can be discovered during the iteration in which they are created; immediately correcting them reduces developer interrupts, a significant contributor to defect creation. Immediately correcting defects reported by users forges a constructive community, replacing product quality with product improvement as the main topic of conversation. Implementing user-suggested improvements that are consistent with your vision and strategy produces community of enthusiastic evangelists.
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
大多数咨询程序员都很糟糕，不应该被允许编写产品代码。
恕我冒昧，大概60%或更多
