64 个嵌套的 If/Else 语句是不是不好？

Posted 2023-03-31

【中文标题】64 个嵌套的 If/Else 语句是不是不好？

【英文标题】：Are 64 nested If/Else statements bad?64 个嵌套的 If/Else 语句是否不好？

【发布时间】：2021-12-22 22:39:07

【问题描述】：

我有点进退两难。我必须对列表进行一些排序。用户可以从 2 个列表中选择，然后选择该列表中的一个元素进行排序。对我来说不幸的是，第二个列表是第一个列表中的子列表。

如果用户只是从父列表中选择，子列表将需要稍微不同的逻辑。我有逻辑可以使用 LINQ 对父列表和/或子列表进行排序，所以我不太担心它的逻辑。

还可以选择升序或降序来使事情变得更糟，至少对我来说是这样。我已经完成了逻辑，看起来总共需要使用 64 个 if/else 语句来合并所有场景。

我的第一反应是，这不是一个很好的解决方法，因为这似乎有很多 if/else 语句。有没有更好的方法来解决这个问题，还是我只需要硬着头皮：

父逻辑：

Positions.Select(x => x.Product).OrderBy(x=>x.Price).AsQueryable();

儿童逻辑：

Positions.Select(x => x.Product).OrderBy(x=>x.Performance.OrderBy(c=>c.AssortmentCategory).Select(c=>c.AssortmentCategory).FirstOrDefault()).AsQueryable();

Positions 和 Performance 都是 ListExtended 的，如果这很重要的话。此外，我正在使用动态 LINQ 库，因为我将获得用户输入，尽管上面没有显示。

Edit1：我忘了说这仅对父列表进行排序。即使他们从子列表中选择一个元素，它也会对父列表进行排序。

【问题讨论】：

使用大量 if/else 可能会降低性能，但它是如此之少，以至于它永远不会影响您的程序。如果你不想让每个人都开心，你可以使用 switch 语句。

基本上，代码中的每个条件（例如if、case）都会为循环复杂度（CC）增加+1，本质上是量度代码中的代码路径。把它想象成一个岔路口。开车从 A 到 B 走那条高速公路总是比走郊区的后街好。对 CC 进行高度衡量的最大影响是对单元测试，因为这意味着他们必须考虑所有变化您的代码状态可以采取的措施。 blog.ndepend.com/understanding-cyclomatic-complexity

我不太明白你在说什么（更多代码会很有用）。我怀疑您可能能够使用 Predicate Builder (albahari.com/nutshell/predicatebuilder.aspx) 之类的东西来构建列名和可组合查询部分的字典（可能是字典），并通过查找某些东西来动态构建查询（而不是通过构建逻辑） if/else if 语句的迷宫

另一个大的圈复杂性打击是可理解性和可维护性。不用担心性能，担心你的代码会变得多复杂。

【参考方案1】：

我会有一个查找字典，它将选择从第一个列表（字符串，int，？不确定您需要什么类型）映射到 Func 并执行

var sortedData = sortDict[selected](args....)

【讨论】：

...和Dictionary<>s 非常适合折叠您从多个if/else 获得的所有圈复杂度。 +1