這種方法有什么問題？

Question

新的代碼審查流程已經到位，現在我的團隊不能將字符串聲明為局部變量，否則提交將不會通過代碼審查。 我們現在要使用常量。

所以這絕對是不允許的，即使我們確定字符串永遠不會在任何其他地方使用

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" ...我們用%s替換someVar ，將整個東西聲明為全局字符串，然后使用String.format(....)
if( name.equals("Audi" ){....}
String value = map.get("key")

有什么想法嗎？ 我想要一些有力的論據。 我已經准備好接受任何以良好爭論為后盾的立場。

謝謝。

Answer 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文件。

Answer 2

當值/ literal多次使用時，為值/文字定義常量是一種很好的編碼風格。

強加的編碼風格強制您為每個字符串文字使用常量。

這種編碼風格的好處是：所有真正應該聲明為常量的字符串文字現在都被聲明為常量。

編碼風格的不良含義是：您 - 開發人員 - 無法決定是否應將字符串文字定義為常量。 這是一個沉重的打擊。

因此，您應該提出您的擔憂，即編碼風格的良好意圖不能彌補您的開發人員資格中的不信任。