喜欢冗长的Linq表达？
喜欢冗长的Linq表达？
提问于 2013-03-01 16:58:48
我突然想到，我把linq语句写得很简单，但别人可能会把它定义为冗长的方式；
一个简单的例子：
return _entries
.Where(x => x.Context.Equals(context))
.Where(x => x.Type == typeof (T))
.Select(x=>x.Value)
.Cast<T>()
.Single();可简化为：
return _entries
.Where(x => x.Context.Equals(context) && x.Type == typeof (T))
.Select(x=>(T)x.Value)
.Single();从长远来看，问题，哪个是更好的编码实践？例如，长(和简单) linq链或具有更复杂选择器/等的短linq链？
假设这些Linq语句将由编译器优化是正确的吗？
回答 4
Stack Overflow用户
回答已采纳
发布于 2013-03-01 17:50:49
从长远来看，哪个是更好的编码实践？
我喜欢简简单单的。更易读。LINQ的全部目的是使代码读起来更像业务域的逻辑。
假设这些Linq语句将由编译器优化是正确的吗？
不；优化是由运行时完成的，而不是由编译器完成的。遵循您描述的模式的"Where“和"Select”子句在运行时被优化为单个“where”对象，以避免创建过多的迭代器。(虽然正如Jon所发现的那样，这有时会产生实际上性能下降了的情况；与几乎所有的“优化”一样，这并不是100%的情况下的胜利。不幸的是，我现在找不到乔恩关于这方面的文章。
Stack Overflow用户
发布于 2013-03-01 17:04:00
不，假设这些LINQ语句是由编译器优化的是不正确的。语法越冗长，就会产生更多的Enumerator对象，因此这两个对象是不等价的。从性能的角度来看，更短的语法(稍微)会更好。
但是，如果您从可读性和编码的角度在这两个语法之间进行选择，我将使用第一个语法，因为它显示了更好的步骤。比起性能，我更喜欢可读性，除非你能证明存在性能瓶颈。
但是，您可能会发现有一个LINQ算子很有用。您的第一个示例重写了：
return _entries
.Where(x => x.Context.Equals(context))
.OfType<T>()
.Select(x => (T)x.Value)
.Single();Stack Overflow用户
发布于 2013-03-01 17:14:23
从长远来看，更好的编码实践是更具可读性的。如果您关心性能，那么测试这两种方法。如果它不值得测试，那么它就不值得优化。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/15162900
复制相关文章
相似问题
腾讯云开发者
