【问题标题】:How to group cases in a switch statment? [closed]如何在 switch 语句中对案例进行分组? [关闭]
【发布时间】:2023-03-29 00:12:01
【问题描述】:

我的 Java switch 语句中目前有 31 个案例。原来有 30 个,现在我又增加了一个。

这是给我this sonar issueReduce the number of non-empty switch cases from 31 to at most 30.

如何减少/分组语句数量并保持原始逻辑?

【问题讨论】:

  • 如果你有这么多案例,也许你一开始就不应该使用 switch 语句......
  • 我没有,我继承了这段代码。我只添加了 1 个,现在遇到了声纳问题
  • 不看代码我们无法告诉你如何保持原有的逻辑。在我理解代码之前,我个人可以提出的大多数建议是“重新配置声纳或删除第 31 个案例”。
  • 如果你想安抚 sonarcoube 并被人工审阅者杀死,请保留 20 个 switch case,并将其余部分移到默认情况下调用的函数中 :-)

标签: java sonarqube switch-statement


【解决方案1】:

声纳是一种工具。不是法官、陪审团或刽子手。它在黑暗中猛烈抨击并告诉您此代码可能是错误的代码样式。不能保证确实如此。声纳规则本身并不是风格指南。样式指南对于软件来说太复杂了,无法应用。不,声纳规则只是一种启发式。过于简单化。因此,这个来自声纳的警告是否真的意味着你应该重构这段代码取决于两个因素:

  1. 一旦你完全理解了导致这个声纳规则的基本原理,你是否同意这个原理?如果没有,请告诉声纳闭嘴(可能通过对整个代码库全局禁用此规则),添加您的第 31 个案例,然后继续。

  2. 如果您确实同意该原则,请检查您拥有的实际代码。 Sonar 正在考虑这个原则,如果应用于你得到的这个开关,意味着你应该重构它。这是正确的吗?可能不是。如果您认为不是,请添加您的第 31 个案例,然后继续。

  3. 如果你还在这里,那么这段代码总是不好;添加第 31 个案例的行为并没有神奇地将其变成糟糕的风格,它总是如此。通过添加第 31 个,您只是使声纳能够告诉您有关它的信息,仅此而已。所以现在,做出决定,哪个原则对你更重要:“不要修复没有破坏的东西”还是“重构糟糕的代码风格”?如果是“Do not fix what aint broken”,请添加您的第 31 个案例,添加注释以告诉声纳关闭,然后继续。

如果您已经完成了整个挑战,请重构此代码。仅仅是因为你现在意识到它现在和一段时间都是不好的风格。

没有一个灌篮的答案(这是一个普遍的趋势:编码很难。如果计算机可以应用的简单规则可以使代码更好,我们都会在坎昆啜饮 mohitos,让计算机完成所有工作编程)。

可能有用的一般原则是有一个Map<X, Handler>,其中X 与表达式X 的类型相同:switch (X) { your 31 cases here }。现在您可以动态设置您的地图,例如将 31 个处理程序填充到 31 个单独的源文件中,并且可能使用SPI;现在你可以用一个实现接口的类创建一个新的 java 源文件,添加一个 @Service 注释,并且,繁荣,它现在是你以前的 switch/case 构造的一部分。无需花时间维护所有“处理程序”的列表,SPI 系统将其自动化。但那是一个相当大的火箭筒,也许你只有一只蚊子。没有细节,我只能给你(通常更复杂的)适用于所有情况的工具。

【讨论】:

    【解决方案2】:

    仅仅因为您的 Sonar 配置为在 31 个案例时触发并不意味着 30 个案例就可以。如果您有这么多案例,特别是如果它们“失败”,您应该考虑使用其他类型的条件逻辑更适合您的需求。没有发布任何代码很难说。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-09-25
      • 1970-01-01
      • 1970-01-01
      • 2010-10-23
      相关资源
      最近更新 更多