Java 程式碼中的典型錯誤。

本資料包含我在與我一起工作的人員的 Java 程式碼中看到的最典型的錯誤。由於顯而易見的原因，靜態分析（我們使用qulice ）無法檢測到所有此類錯誤，這就是為什麼我決定將它們列在這裡。所有這些錯誤通常都與物件導向編程，特別是 Java 相關。

類別名

你的類別應該是現實生活中物件的抽象，沒有「 驗證器 」 、「控制器 」、 「管理器 」等。如果你的類別名稱以“-er”結尾，那就是糟糕的設計。當然，像Apache 的 StringUtils、 FileUtils和 IOUtils這樣的反模式幫助器類別就是糟糕的設計模式的很好的例子。切勿加上字尾或前綴來區分介面和類別。例如，所有這些名稱都很糟糕： IRecord、 IfaceEmployee或 RecordInterface。通常，介面名稱是現實物件的名稱，而類別名稱應該解釋實作細節。如果沒有關於實現的具體信息，則名稱“ Default ”、“ Simple ”或類似的名稱即可。例如： class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

方法名稱

方法可以傳回「 something」或傳回「 void」。如果一個方法傳回某些內容，那麼它的名稱應該解釋將傳回什麼。例如（不要使用“ get ”前綴）： boolean isValid(String name); String content(); int ageOf(File file); 如果傳回“ void ”，則名稱應該闡明該方法的作用。例如： void save(File file); void process(Work work); void append(File file, String line); 此規則只有一個例外 - JUnit測試方法。它們的描述如下。

測試方法名稱

JUnit 測驗中的方法名稱必須建構為不含空格的英文句子。用一個例子更容易解釋這一點： /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } JavaDoc 的第一句話以您正在測試的類別的名稱開頭，後面跟著“ can ”，這一點很重要。 所以，第一句話應該總是像「某人可以做某事」這樣的短語。方法名稱將說明相同的內容，但沒有測試主題。如果我將其添加到方法名稱的開頭，我會得到一個完整的英文句子，如上面的範例所示：「 HttpRequest returns its content in unicode」。請注意，測試方法名稱不以“ can ”開頭。只有 JavaDoc 註解以「 can 」開頭。另外，方法名稱不應該以動詞開頭（ 譯者：顯然，作者指的是動詞的祈使語氣）。聲明測試方法時指示拋出例外是一種很好的做法。

變數名稱

避免使用複合變數名稱，例如 timeOfDay、 firstItem或 httpRequest。我的意思是類別變數和方法變數。變數名稱應該足夠長，以避免其範圍出現歧義，但如果可能的話也不要太長。名稱必須是單數或複數名詞。例如： 有時，如果建構函式將輸入資料儲存到已建立的物件中，建構函式參數和類別欄位之間可能會發生衝突。在這種情況下，我建議透過刪除元音來建立縮寫。範例： 在大多數情況下，最好的變數名稱是對應類別的名稱。只需將其大寫即可： 但是，切勿對像or 這樣的原始類型執行相同的操作。當有多個具有不同特徵的變數時，您也可以使用形容詞。例如： List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

建構函數

無一例外，應該只有一個建構函數將資料儲存到物件變數中。所有其他建構函式必須使用不同的參數來呼叫此建構函式： public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

一次性變數

不惜一切代價避免一次性變數。我所說的「一次性」是指一次性使用的變數。就像這個例子一樣： String name = "data.txt"; return new File(name); 變數只使用一次，程式碼可以簡化為： return new File("data.txt"); 有時，在極少數情況下 - 主要是由於更好的格式 - 可以使用一次性變數。但是，請盡量避免此類情況。

例外情況。

當然，你永遠不應該「吞掉」異常；它們應該被拋出得盡可能高。私有方法的異常必須在外部處理。切勿使用異常來控制流程。範例中的程式碼不正確： int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } 說真的，如果 IOException 說“磁碟已滿”，您會假設檔案大小為零並繼續嗎？

縮排。

對於縮排，一般規則是括號必須結束行或在同一行結束（相反的規則適用於右括號）。在下面的範例中，程式碼不正確，因為第一個括號未在同一行結束並且後面有字元。第二個括號也有同樣的問題，因為它前面有字符，而且當前行沒有左括號。 final File file = new File(directory, "file.txt"); 正確的縮排應如下所示： StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); 縮排的第二個重要規則是應在一行上放置盡可能多的內容 - 80 個字元以內。上面的例子是無效的，因為它可以被壓縮： StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

冗餘常數。

當您想要在類別方法之間共用對資訊的存取權時，應該使用類別常數，並且此資訊是您的類別的特徵（ ！ ）。不要使用常數來替換字串或數字文字 - 非常糟糕的做法，它會導致程式碼污染。常量（像其他 OOP 物件一樣）必須在現實世界中有意義。這些常數在現實世界中的意義是什麼： class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } 另一個常見的錯誤是在單元測試中使用常數以避免在測試方法中重複字串/數字文字。不要那樣做！每個測試方法必須對其自己的一組輸入值進行操作。在每個新的測試方法中使用新的文字和數字。測試是獨立的。那麼為什麼它們應該共享相同的輸入常數呢？

測試數據耦合。

以下是測試方法中掛鉤的範例 User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff"))：在最後一行中，我們將「 Jeff」與第一行中指定的相同字串文字連接起來。如果幾個月後，有人想要更改第三行中的值，他/她將不得不花費額外的時間搜尋以查看此方法中也使用了「 Jeff 」。為了避免這種資料阻塞，您應該引入一個變數。