【问题标题】:what's wrong with this approach?这种方法有什么问题?
【发布时间】:2016-04-14 19:56:02
【问题描述】:

一个新的代码审查流程已经到位,现在我的团队决不能将字符串声明为局部变量,否则提交将无法通过代码审查。我们现在要改用常量。

所以这是绝对不允许的,即使我们确定字符串永远不会在任何其他地方使用

String operationId = "create"; 

这是应该改用的:

private static final String OPERATION_ID = "create";

虽然我完全同意对在代码中出现 +2 次的字符串使用常量……但我只是觉得如果字符串只使用一次就完全没有能力在适当的位置声明一个字符串是过度的。

为了清楚起见,以下所有内容在任何情况下都不允许:

  • String div = "div1";
  • Catch(Exception ex){ LOGGER.log("csv file is corrupt") }
  • 字符串连接String str = "something ...." + someVar + "something" ...我们将someVar替换为%s,将整个东西声明为全局字符串,然后使用String.format(....)

  • if( name.equals("Audi" ){....}

  • String value = map.get("key")

有什么想法吗?我想要一些强有力的论据。我已准备好接受任何有充分理由支持的立场。

谢谢。

【问题讨论】:

  • 可能更多的是代码审查问题?
  • 您还可以与List<String> 互动吗? IE。 String elm0 = lst.get(0)?
  • @Mshnik 我看不出这有什么关系;那里没有直接的字符串。
  • 我们甚至不应该将字符串定义为常量。它们都被外部化到属性文件中。 (这虽然经常令人讨厌,但确实使本地化变得更加容易)。
  • 我个人认为将此要求扩展到日志记录是很疯狂的。即使您需要本地化日志文件,您也可以通过字符串作为属性键,然后您必须将其设为常量?

标签: java string coding-style constants


【解决方案1】:

首先,让我们抛弃您的假设:所描述的方法本质上没有任何错误。

这与在多个地方使用的字符串无关,而是关于易于查找和记录的常量,以及您的代码一致。

private static final String OPERATION_ID = "create";

真的,这在其他地方任何地方都没有使用过吗?如果我将其更改为字符串“beetlejuice”,什么都不会破坏?如果某些东西会中断,那么其他东西正在使用这个常量......如果“其他东西”恰好是不同语言的代码库,这就是它们不共享字符串常量的原因——这是例外,而不是规则.一致性!


也就是说,有一些事情我会以稍微不同的方式标准化,但我仍然会标准化它们:

我建议在枚举的构造函数中允许字符串字面量:

public enum Operation {
    CREATE("create"),
    ...
}

因为在这里,枚举是代码中引用的常量,而不是字符串文字。将常量声明为枚举或private static final String 对我来说是等价的,没必要两者都做。

此外,我不会在任何会破坏 IDE 警告您丢失字符串的能力的地方使用此模式——例如,从 .properties 文件中查找字符串。当您在 .properties 文件中查找一个不存在的键时,许多 IDE 会给您适当的警告,但是根据您的 IDE 的智能程度,额外的间接级别可能会破坏这一点。

Catch(Exception ex){ LOGGER.log("csv file is corrupt") }

这对我来说有点灰色地带 - 这是仅限内部消息吗?这些日志是否只有您(开发人员)才能看到,还是它们也是为了用户的利益?

如果只针对应用程序的开发者,这些可能不需要本地化。

如果您确实希望用户查看日志,那么应该将它们外部化到 .properties 文件中。

【讨论】:

    【解决方案2】:

    当值/文字被多次使用时,为该值/文字定义一个常量是一种很好的编码风格。

    强加的编码风格迫使您为每个字符串文字使用一个常量。

    这种编码风格的好效果是:所有真正应该被声明为常量的字符串文字现在都被声明为常量。

    这种编码风格的坏含义是:您 - 开发人员 - 无法决定是否应将字符串文字定义为常量。这是一个沉重的打击。

    因此,您应该提出您的担忧,即编码风格的良好意图并不能弥补对您的开发人员素质的不信任。

    【讨论】:

      猜你喜欢
      • 2013-06-10
      • 2012-04-08
      • 2016-09-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-09-03
      相关资源
      最近更新 更多