使用 C# 3.0 特性有什么缺点吗？答案

【问题标题】：Are there any disadvantages of using C# 3.0 features?使用 C# 3.0 特性有什么缺点吗？
【发布时间】：2011-01-19 18:16:08
【问题描述】：

我喜欢 C# 3.0 的特性，尤其是 lambda 表达式、自动实现的属性或在适当的情况下还隐式类型化的局部变量（var 关键字），但是当我的老板透露我正在使用它们时，他让我不要使用任何 C#工作中的 3.0 功能。有人告诉我，这些功能对于大多数开发人员来说不是标准的和令人困惑的，而且它的实用性值得怀疑。我被限制只能使用 C# 2.0 功能，他也在考虑禁止匿名方法。

由于我们的目标是 .NET Framework 3.5，我看不出这些限制的任何原因。在我看来，也许唯一的缺点是我的几个同事和老板（也是程序员）必须学习一些 C# 3.0 的基础知识，这应该不难。你怎么看待这件事？我的老板是对的，我错过了什么吗？在以 C# 为主要编程语言的开发公司有这样的限制吗？

【问题讨论】：

你的老板听起来像一个嗡嗡声
你的老板在 C# 3 语言规范中的特性是非标准的具体陈述中得出的结论是错误的。
@280Z28 - 我怀疑在老板口中“不标准”的意思是“我们不使用它们。”
@tvanfonnon：那老板应该说“不允许”。我并不期望老板所说的一切都同意，但我希望老板了解他负责的规则的基本沟通。
是时候跳船了。

标签： c#-3.0 language-features

【解决方案1】：

有些人只是害怕改变，因为也许你会用花哨的新技术让他们看起来都很愚蠢。也可能是你的老板不希望团队学习新事物，而不是用老式的方式完成工作。

var 关键字当然可以被滥用，但在大多数情况下会减少冗余代码。 LINQ 是您希望从 .Net 3.5 获得的主要功能，因为您必须编写的代码量可以节省大量时间。你的老板应该鼓励你使用它。此外，基类库现在将委托作为参数，因此不使用它们会极大地限制自己。 Lambda 只是一些花哨的语法糖，可以让代表更干净。

我会向您推荐Effectively Integrating into Software Development Teams 和Leading by Example。关于如何应对害怕改变的团队的两篇非常棒的文章。

【讨论】：

【解决方案2】：

也许您可以每周针对每个功能向所有人进行一次演示，并让一些开发人员站在您这边，帮助说服管理层了解这些好处。

我最近从一个最前沿的 C# 房子搬到了一个 C# 房子，它主要在 dot.Net 1.1 和一些 2.0 项目上运行，主要只使用 1.1 功能。幸运的是，管理层远离代码。大多数开发人员都喜欢新框架中的所有新功能，他们只是没有时间或不愿意自己弄清楚它们。一旦我设法向他们展示了如何让自己的生活更轻松，他们就开始自己使用它们，我们已经迁移了几个项目以获得新的语言功能和更好的工具优势。

【讨论】：

【解决方案3】：

我有过类似的经历（被要求不要使用泛型，因为这可能会让我的同事感到困惑）。

事实是，我们现在使用泛型，而我的同事都没有遇到问题。他们可能没有掌握如何创建泛型类，但他们确实了解如何使用它们。

我对此的看法是，任何开发人员都可以学习如何使用这些语言功能。起初它们可能看起来很先进，但随着人们习惯它们，新鲜感的冲击就会减弱。

使用这些功能（或任何新的语言功能）的主要论点是，这是一种简单易行的方法，可以帮助我的同事提高技能，而不是停滞不前。

至于您的特定问题 - 不使用 lambdas。 BCL 的许多更新都具有将委托作为参数的重载 - 在许多情况下，这些最容易表示为 lambda，不以这种方式使用它们会忽略 BCL 的一些新的和更新的用途。

关于您的同行无法学习 lambdas 的问题 - 我发现 Jon Skeets C# 以一种易于理解且真正令人大开眼界的方式深入处理了它们如何从代表演变而来。我建议你为你的老板和同事准备一份副本。

【讨论】：

最近我一直在讨论如何在 C# 中做一些事情，由于我对 C# 3 特性的了解更加深入，我可以从其他方面翻译许多范式和模式语言到 C#，而其他人一直在吹嘘 C# 是多么静态和糟糕。这让我意识到在你抱怨之前你必须真正了解一些事情。这也让我意识到，当你对一门语言非常了解时，用它编程会容易得多。
可悲的是，“任何称职的开发人员”.. 对于公司中试图与他拥有的相当软弱的人相处的中层管理人员根本没有用处。我不想在那里工作，但我理解这个问题。也许你没有意识到在那种环境下要真正解雇蹩脚的程序员并获得优秀的程序员是多么困难。
我确实意识到这一点......而且我意识到我比其他人更有才华。但这并不意味着您应该远离新的语言功能，您可以将学习它们作为一项要求。
我赞成为您的老板和您的每位同事获取一份 C# 深度副本的建议。以防万一，周围也有一些备用副本可能不是一个坏主意。您永远不知道在紧急情况下何时需要一份副本。
@Jon Skeet：当然可以，这是你的书！ ;)

【解决方案4】：

您的老板需要了解语言（和其他）改进旨在为开发人员提供更多功能，并使他们更有效地完成手头的任务，并且如果他不打算允许他们未知那么原因：

开发团队没有发挥最大潜力。
公司没有从提高效率/生产力中受益。

就像其他人所说的那样，如果开发人员无法跟上他们每天使用的语言的一些最新改进，那么他们就是不值一提的。我怀疑你的老板最近没有做太多的编码，是他无法理解最新的语言改进促使这个决定。

【讨论】：

【解决方案5】：

我特别喜欢 C# 3.0 的特性 lambda 表达式，自动实现属性或在适当的情况下也隐式类型的局部变量（var 关键字），但是当我的老板透露我正在使用它们，他问我不要在工作中使用任何 C# 3.0 功能。一世被告知这些功能不是对大多数人来说是标准且令人困惑的开发人员和它的用处是值得怀疑。

他说得有道理。

按照这种思路，让我们针对泛型集合制定一条规则，因为List<T> 没有任何意义（尖括号？wtf？）。

当我们这样做的时候，让我们消除所有接口（你什么时候需要一个没有任何实现的类？）。

见鬼，让我们继续消除继承，因为现在它太棘手了（is-a？has-a？我们不能只是朋友吗？）。

使用递归是解雇的理由（Foo() 调用 Foo()？你肯定是在开玩笑！）。

Errrm...回到现实。

并不是 C# 3.0 的特性让程序员感到困惑，而是这些特性让你的老板感到困惑。他熟悉一种技术，并且固执地拒绝放弃它。你即将进入~~暮光地带~~Blub Paradox:

程序员非常重视他们的最喜欢的语言，我不想要伤害任何人的感情，所以解释这一点，我将使用称为 Blub 的假设语言。 Blub 正好落在中间抽象连续体。它不是最强大的语言，但它更比 Cobol 或机器强大语言。

事实上，我们假设的 Blub 程序员不会使用任何一个他们。他当然不会编程机器语言。就是这样编译器适用于。至于 Cobol，他不知道怎么会有人得到用它做任何事情。它甚至没有有 x（您选择的 Blub 功能）。

只要我们假设的 Blub 程序员低头看电源连续统，他知道他在往下看。不如 Blub 强大的语言是显然不那么强大，因为他们缺少他使用过的一些功能到。但是当我们假设的 Blub 程序员看着另一个方向，向上的权力连续体，他没有意识到他在抬头。什么他看到的只是奇怪的语言。他可能会考虑他们与 Blub 等效，但具有所有这些其他毛茸茸的东西都扔进去了也是。 Blub 对他来说已经足够好了，因为他在 Blub 中思考。

当我们切换到程序员使用任何权力更高的语言然而，我们发现他在转身看不起Blub。你怎么在 Blub 中完成任何事情？它没有甚至还有。

C# 3.0 并不难。当然，您可以滥用它，但对于任何拥有超过一周 C# 3.0 经验的程序员来说，这并不难或令人困惑。你老板的技能刚刚落后，他想把团队的其他人拉到他的水平。不要让他！

继续使用匿名函数、var 关键字、自动属性，以及您心目中的内容。你不会因此失去工作。如果他对此感到生气，请一笑置之。

【讨论】：

好吧，你可能会因此丢掉工作……但我不确定这是不是一件坏事。

【解决方案6】：

有人告诉我，这些功能对于大多数开发人员来说并不标准且令人困惑，而且它的实用性值得怀疑。我被限制只能使用 C# 2.0 功能，他也在考虑禁止匿名方法。

大概翻译成你老板的意思吧……

这些功能让我很困惑，而且我不觉得它们有用，因为我不理解它们。

这是the Blub paradox 的明显症状（好吧，或者只是纯粹的懒惰）。无论哪种方式，他所说的都没有任何价值，如果他继续走这条路，你应该开始寻找另一份工作。

【讨论】：

【解决方案7】：

对于某些功能的长期影响尚无定论，但如果他们的主要理由是“让其他开发人员感到困惑”或类似的事情，我会担心人才的质量。

【讨论】：

【解决方案8】：

如果 Microsoft 没有定义标准并且这些是他们添加到非 Microsoft 语言的功能，我会说你的老板可能有一点。但是，由于 Microsoft 定义了该语言并在实现 .NET 3.5（和 4.0）的重要部分时使用了这些特性，我会说忽略它们是愚蠢的。您可能不会选择使用其中的一些——例如，var，由于编码标准，可能无法在所有环境中接受——但避免新功能的一揽子政策似乎不合理。

更棘手的一点是您应该何时开始使用新功能，因为它们可能会造成混淆并可能会延迟开发。一般来说，我选择在新项目中使用新的语言特性和平台元素。当功能/框架增强出现时，我经常避免在当前正在开发的项目中使用它们，推迟到下一个项目。在一个漫长的项目中，我可能会在一个重要的里程碑上介绍它们如果重新架构的数量很小或者该功能值得更改。通常，我会等到项目到期进行重大更改，然后评估是否有必要重构为新功能。

【讨论】：

我会犹豫是否仅仅因为它来自 MS 实验室就可以安全使用语言功能。无法保证某项功能在未来不会成为一个坏主意，因此在使用新语言功能时应考虑此类因素。
关于框架增强，我倾向于同意。具有语言功能，则更少。您使用的任何功能/框架元素都需要通过气味测试——这是好的代码吗？框架元素也需要对长寿有一些合理的希望。根据我的经验，语言特性通常更稳定，也更保守。阅读 @Eric Lippert 的博客 (blogs.msdn.com/ericlippert/default.aspx) 在这方面非常有用。
@user：我根本不会这么认为。我想看看 VS2008 已经发布了几年的事实，而 VS2010 已经发布了大约六个月的测试版（具有新的语言功能）。全球范围内有足够的经验使用新功能，可以了解 Microsoft 是否已经下蛋。

【解决方案9】：

如果该项目从现在开始是严格的 C# 3+，那么您不会通过包含这些项目来破坏构建。但是，在使用它们之前，您应该注意以下事项：

如果项目负责人做出决定并投反对票，您将无法使用它们。
除此之外，您应该在使代码更易于维护的地方使用它们。
您不应以令人困惑或不必要的方式使用它们，因为它们不会显着提高代码的可维护性。这确实意味着您不应该在代码实际上相同或几乎没有改进的情况下使用它们。

【讨论】：

问题是，如果使用功能令人困惑，部分是主观的，很大程度上取决于您对它的使用程度。
如果项目负责人投反对票，您可能无法使用它们，但这样的项目负责人会错误。

【解决方案10】：

不管你喜不喜欢，如果你打算在任何情况下使用 LINQ，你将不得不使用一些 C# 3.0 语言规范。

如果您的老板想要使用您从 3.5 中获得的功能集，他将不得不对它们进行热身，这些功能集数量众多，值得您花时间投资。

此外，根据我在领导团队中的经验，我发现使用 3.0 规范实际上有助于开发人员的可读性和对代码库的理解。开发人员花了大约一周的时间试图理解语法的含义，但一旦他们明白了，他们更喜欢新方法而不是旧方法。

【讨论】：