您会将LINQ查询抽象为扩展方法吗？

Question

在我目前的项目中,我们为代码指标"可维护性指数"和"Cyclometic Complexity"设定了一些目标.可维护性指数应为60或更高,Cyclometic Complexity为25或更低.我们知道60和更高的可维护性指数相当高.

我们还使用了很多linq来过滤/分组/选择实体.我发现这些linq查询在维护性指数上得分并不高.将这些查询提取到扩展方法中,可以给我一个更高的可维护性指数,这很好.但是在大多数情况下,扩展方法不再是通用的,因为我将它们与我的类型而不是泛型类型一起使用.

例如,以下linq-query vs扩展方法:

Linq查询

List.Where(m => m.BeginTime >= selectionFrom && m.EndTime <= selectionTo)

扩展方法:

public static IEnumerable<MyType> FilterBy(this IEnumerable<MyType> source, DateTime selectionFrom, DateTime selectionTo)
{
    return (IEnumerable<MyType>)source.Where(m => m.BeginTime >= selectionFrom && m.EndTime <= selectionTo);
}

List.FilterBy(selectionFrom, selectionTo);

扩展方法为我提供了6个点的可维护性指数改进,并提供了一个很好的流利语法.另一方面,我必须添加一个静态类,它不是通用的.

关于什么方法的任何想法会对你有利吗？或者可能对如何重构linq查询以提高可维护性指数有不同的想法？

Answer 1

您不应该为了指标而添加类.任何指标都旨在使您的代码更好,但盲目遵循规则,即使是最好的规则,也可能实际上损害您的代码.

我认为坚持某些可维护性和复杂性指数并不是一个好主意.我相信它们对于评估旧代码很有用,即当你继承一个项目并需要估计它的复杂性时.然而,提取一个方法是荒谬的,因为你没有得到足够的分数.

只有重构才能重构代码. 这样的价值是一个复杂的人类度量指标,无法用数字表达,估计它正是编程经验的关键 - 在优化与可读性之间找到平衡与清洁API 与酷代码与简单代码与快速发货与广义与规范等之间的平衡.

这是您应该遵循的唯一指标,但并不总是每个人都同意的指标...

至于你的例子,如果反复使用相同的LINQ查询,那么创建一个EnumerableExtensionsin Extensions文件夹并在那里提取它就非常有意义.但是,如果它使用了一次或两次,或者可能会发生变化,那么详细查询会更好.

我也不明白为什么你说它们不是通用的,有些负面的含义.你到处都不需要泛型!实际上,在编写扩展方法时,您应该考虑可以选择的最具体的类型,以免污染其他类的方法集.如果您希望您的助手只能使用IEnumerable<MyType>,那么完全声明扩展方法绝对没有羞耻感this IEnumerable<MyType>.顺便说一下,你的例子中有多余的转换.摆脱它.

不要忘记,工具是愚蠢的.我们人类也是如此.