在哪里画线 - 是否有可能过多地爱LINQ？

我最近找到了LINQ并喜欢它.我发现很多场合使用它比速记版本更具表现力,但是一位同事传达了关于我滥用这项技术的评论,现在让我自己猜测.我的观点是,如果一项技术有效运作且代码优雅,那么为什么不使用呢？那是错的吗？我可以花费额外的时间来编写"longhand"进程,虽然生成的代码可能快几毫秒,但是代码的数量是2-3倍,因此可能存在错误的机率增加2-3倍.

我的观点错了吗？ 我应该用手写代码而不是使用LINQ吗？这不是LINQ的设计目的吗？

编辑:我说的是LINQ to objects,我没有使用LINQ to XML这么多而且我使用过LINQ to SQL但我并不喜欢LINQ to objects这些风格.

我必须同意你的观点 - 如果它更有效率地编写和优雅,那么几毫秒.编写额外的代码为bug提供了更多的空间,而且需要测试的是额外的代码,而且最重要的是需要维护的额外代码.想想那些将要进入你身边的人并维护你的代码 - 他们会感谢你写好优雅的易读代码,感谢你们编写代码快几毫秒!

但要注意,当你考虑到更大的影响时,这几毫秒的成本可能会很大.如果几毫秒是数千次重复循环的一部分,那么毫秒加起来很快.

是的,你可以非常喜欢LINQ - Single Statement LINQ RayTracer

你在哪里划线？我会说使用LINQ,因为它使代码更简单,更容易阅读.

LINQ版本变得更难以理解的那一刻,非LINQ版本是时候交换,反之亦然.编辑:这主要适用于LINQ-To-Objects,因为其他LINQ风格有其自身的好处.

它不可能过多地爱Linq对象,这是一个非常棒的技术!

但严重的是,任何使你的代码易于阅读,易于维护并完成预期工作的东西,那么你就不会尽可能地使用它.

LINQ应该用于对来自各种来源的数据进行过滤,排序,聚合和操作,尽可能直观和富有表现力.我会说,无论你觉得它是最干净,最具表现力和最自然的语法来做你正在尝试做的事情,并且不要对此感到内疚.

如果你开始讨论文档,那么可能是时候重新考虑你的立场了.

在这种情况下,记住优化的黄金规则非常重要:

不要这样做

专家:不要这样做

您绝对不应该担心"滥用"linq,除非您可以明确地将其识别为性能问题的原因

像任何东西一样,它可能被滥用.只要你远离明显的糟糕决定,例如

var v = List.Where(...);
for(int i = 0; i < v.Count(); i++)
{...}

并且了解执行的不同之处,那么它很可能不会比速记方式慢得多.根据Anders Hejlsburg(C#架构师)的说法,C#编译器并不是特别擅长优化循环,但它在优化和并行化表达式树方面要好得多.及时,它可能比循环更有效.List <>的ForEach版本实际上和for循环一样快,虽然我找不到证明这一点的链接.

PS我个人最喜欢的是ForEach <>鲜为人知的堂兄IndexedForEach(利用扩展方法)

List.IndexedForEach( (p,i) => 
 {
     if(i != 3)
        p.DoSomething(i);
 };