IntelliJ IDEA：程式碼樣式與格式

現代工具使開發過程變得更加容易。特別是，可以更輕鬆地監視程式碼的風格，嘗試最大程度地減少其「未經授權」的格式。在這篇評論中，我建議您熟悉一下 IntelliJ Idea IDE 為開發人員提供了哪些工具，以使程式碼易於閱讀且易於理解。

介紹

程式語言與人們所說的語言非常相似。唯一的區別是，這是一種特殊的語言，最初用於與電腦進行通信，以便向電腦解釋我們想要從中得到什麼。但不可能與計算機進行一對一的交流。即使當您開始學習程式語言時，您也會查看一本書或一些教育資源，例如 JavaRush。在此原始程式碼中，您看到了電腦能夠理解的程式碼。但當您了解 Java 語言時，您也應該理解它。與任何語言一樣，程式設計也有一些形成程式碼的規則。例如，在文明社會中用柵欄書寫被認為是不禮貌的行為，而在Java中用大寫字母呼叫方法則被視為嚴重違反代碼風格。Java 程式碼的格式化規則在Java 程式碼約定文件中製定。此外，程式碼風格可以調節更小的細節，例如縮排。當使用版本控制工具時，想像一下當每個人都保存縮排為製表符或縮排為空格的檔案時整個噩夢。對於只需要用一種方法檢查編輯情況的人來說，但由於將空格更正為製表符，整個文件將被更改，反之亦然，這會是什麼樣子。當然，與普通語言一樣，風格可能會根據使用地點的不同而有所不同。例如，在 Internet 上您可以找到Google Java 樣式指南或Twitter Java 樣式指南。對於這篇評論文章，我們需要一個測試對象。讓我們使用 Gradle 專案建置系統的服務。它將允許我們使用模板建立一個新項目以快速啟動。Gradle 有一個很棒的插件：Build Init Plugin。讓我們轉到新目錄並在那裡執行命令： gradle init --type java-application 之後，啟動 IntelliJ Idea。如果您看到一個窗口，其中包含已開啟的項目（您將看到程式碼編輯器、專案結構樹），請使用 關閉該項目File -< Close Project。現在，在歡迎視窗中，我們將執行"Import Project"並匯入我們的新專案。導入時，設定標誌"Use autoimport"。讓我們弄清楚是否有可能藉助現代開發工具以某種方式簡化生活。

在 Idea 中格式化程式碼

導入專案後，按組合鍵Ctrl+N進入班級AppTest。該類別是預設的測試類別。它看起來像這樣：

import org.junit.Test;
import static org.junit.Assert.*;

public class AppTest {
    @Test public void testAppHasAGreeting() {
        App classUnderTest = new App();
        assertNotNull("app should have a greeting", classUnderTest.getGreeting());
    }
}

什麼立即引起您的注意？一行方法聲明的註解，看起來很醜，同意。如何解決這個問題？IntelliJ Idea 有一個"Code"用於各種程式碼操作的選單部分。其中一種操作是"Reformat Code"組合鍵Ctrl + L。應用後，註釋將在一行，方法本身將在另一行。值得注意的是，此操作是在選定的程式碼部分上執行的。而如果沒有這個東西，則會對所有內容進行格式化操作。現在讓我們新增一個新的測試方法：

@Test
public void testSummOfOddNumbers() {
	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
	Integer result = data.stream().filter(number -> number % 2 == 0).reduce((n1, n2) -> n1 + n2).get();
	assertThat(result, is(12));
}

和兩個進口：

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

可以看到，對Stream的操作放在一行。但是，如果我們想確保其呼叫被連結的方法總是在某些點分割成新行怎麼辦？一方面，我們可以手動完成此操作。但請記住，我們希望一切都為我們服務。畢竟，我們時不時會忘記，而且各地的程式碼格式也會變得不同，這並不好。原來你需要編輯Idea執行格式化的規則。在選單中選擇創意項目File -> Settings（或點選Ctrl + Alt + S）。在設定視窗的搜尋欄位中，輸入「代碼樣式」。在「程式碼樣式」部分中，不僅可以指定 Java 的設定。但現在我們對 Java 有興趣。如您所見，設定分為幾個選項卡。最有用的是更改的結果將顯示在視窗右側的範例中： 正如您在螢幕截圖中看到的，我們可以將“鍊式方法呼叫”的設定指定為“wrap always”，即 始終拆分合併方法呼叫。現在我們再測試一下按格式化，看看是否真的有效！但有時需要在一般格式化規則之外對某些程式碼進行格式化。讓我們按如下方式設定格式： 若要停用格式設置，必須在「程式碼樣式」部分中啟用停用格式標記的支援： 現在我們可以更改測試程式碼，使其格式保持我們編寫時的格式：

@Test
public void testSummOfOddNumbers() {
	List<Integer> data = Arrays.asList(1, 4, 2, 3, 6, 7, 9);
	// @formatter:off
	Integer result = data.stream().filter(number -> number % 2 == 0)
                             .reduce((n1, n2) -> n1 + n2)
                             .get();
	assertThat(result, is(12));
	// @formatter:on
}

是的，如果您注意到：當您按 Tab 時，Idea 會將其解釋為您的空格（預設行為）。但您可以在程式碼樣式中變更此設定： 正如您所看到的，有各種各樣的設置。您可以在此處閱讀有關程式碼樣式設定的更多資訊：「Idea 幫助：程式碼樣式」。還有另一個重要的格式化功能 - 導入格式。它是單獨執行的，被呼叫"Optimize Imports"並位於選單項目中Code -> Optimize Imports（Ctrl + Alt + O）。匯入最佳化會刪除不必要的匯入，並根據「Java 程式碼樣式」設定的「匯入」標籤中的設定將它們放置在正確的順序中。另外，如果您希望自動進行格式化，好消息是您可以使用「儲存操作」外掛程式來完成此操作。

將設定分發給團隊

太好了，我們在上面看到我們可以自訂格式樣式以適合我們。但這種風格如何運用在團隊中呢？很簡單。有幾種選擇。最簡單的一種是保存圖表。透過檔案 -> 設定（或按 Ctrl + Alt + S）開啟 Idea 設定。在“程式碼樣式”部分我們可以看到“Scheme”字樣。這是我們的格式化方案。預設情況下，會指定一個名稱為 Default 的方案，旁邊是 IDE 註解：這表示此設定僅適用於我們的 IDE，不會影響任何人。若要製作「自訂」方案，請按一下右側的按鈕進行「複製」並為其命名，例如：JavaRush 之後我們將能夠匯入或匯出設定： 另一個選擇是導入 Idea 設定： 第三個選項是設定儲存庫。有關使用設定儲存庫的更多信息，請參閱文件「IntelliJ Idea 說明：設定儲存庫」。關於在團隊中分發單一樣式的主題，我也忍不住注意到 Eclipse IDE 對樣式的良好支援。為此，您需要安裝一個單獨的插件：透過檔案 -> 設定（Ctrl + Alt + S）打開 Idea 設定，然後轉到插件部分。要搜尋新插件，請點擊 按鈕"Browse Repositories"，之後我們將在搜尋視窗中找到 Eclipse Code Formatter 插件。 現在，安裝後，您需要重新啟動 Idea - 這是標準流程。之後，在同一個地方，在 Idea 設定中，我們會發現一個新部分：「Eclipse Code Formatter」。可以在此處找到Eclipse 格式檔案的範例。它看起來像這樣：

收緊要求

除了 Idea 工具之外，您還可以使用建置系統外掛程式來收緊要求。沒有辦法檢查一個人是否使用了格式。如果團隊有5個人的話，還是有可能的。如果公司有100人，那是不切實際的。是的，即使是五個也很難追蹤。為什麼要在這上面浪費時間呢？如果違反某些規則，則禁止收集項目要容易得多。事實上，這是一個完全獨立的主題，稱為「檢查代碼」。出於本文的目的，我只想展示它是如何運作的。Gradle 最常見的插件之一（因為它收集了我們的項目，如果你還記得的話）是pmd。要啟用它，只需轉到 gradle 專案的建置腳本（專案根目錄中的 build.gradle 檔案）並在其餘插件旁邊指定 pmd：

plugins {
    // Apply the java plugin to add support for Java
    id 'java'
    // Check source code
    id 'pmd'
    // Apply the application plugin to add support for building an application
    id 'application'
}

現在我們可以在那裡進行更詳細的設定：

pmd {
    ignoreFailures = false
    pmdTest.enabled = true
    ruleSets = [
            'java-basic',
            'java-braces',
            'java-clone',
            'java-codesize',
            'java-comments',
            'java-controversial',
            'java-coupling',
            'java-design',
            'java-empty',
            'java-finalizers',
            'java-imports',
            'java-optimizations',
            'java-strictexception',
            'java-strings',
            'java-typeresolution',
            'java-unnecessary',
            'java-unusedcode'
    ]
}

即使在我們的專案中，一切都不再美好。讓我們運行 gradle build 並得到一個錯誤。令人高興的是，在組裝過程中會產生一份報告。如果出現錯誤，我們將收到以下訊息：

BUILD FAILED in 35s
6 actionable tasks: 6 executed
7 PMD rule violations were found. See the report at: file:///C:/_study/codestyle/build/reports/pmd/main.html

如果我們查看報告，我們會看到類似以下內容： 此外，在「問題」列中，有一個指向 pmd 插件網站上的問題描述的連結。例如，對於錯誤“headerCommentRequirement required”，連結位於：pmd - CommentRequired。這個錯誤提示我們我們的類別沒有 JavaDoc。可以使用模板配置 JavaDoc 在類別上的存在： 並指定文件頭的內容： 之後，我們可以將 App 類別上面的註解轉換為 JavaDoc，並在新的 Build 中看到錯誤已經消失。

底線

程式碼風格對於高效率的專案非常重要。按照通用規則寫出的漂亮程式碼是你的同事會更容易、更快速地理解它的保證，並且不會說幾句關於你的情話。有了現代的開發工具，遵守規則並不是那麼困難。我希望這篇評論表明情況確實如此。好吧，像往常一樣，關於這個主題的一些材料：

• 來自 JetBrainsTV 的影片：“檢查代碼 (IntelliJ IDEA) ”
• 《使用 Gradle 插件進行程式碼分析》回顧
• 課程“自動化程式碼品質”

#維亞切斯拉夫