IntelliJ IDEA：編碼風格和代碼格式

編程語言與口頭語言非常相似。唯一不同的是，它是一種特殊的語言，其主要目的是促進與計算機的交流，以便向計算機解釋我們想讓它做什麼。但是你無法與計算機進行個人對話。當您開始學習編程語言時，您會查看書籍或一些教育資源，例如 CodeGym。此資源向您展示了計算機可以理解的代碼。但是您在學習 Java 語言時也應該理解它。與任何語言一樣，編程中採用了一些格式約定。例如，在禮貌的社會中，這樣寫會被認為是不禮貌的。在 Java 中，方法名稱以大寫字母開頭是對編碼約定的嚴重違反。 Java 代碼的規則在Java 編程語言的代碼約定文檔中給出。編碼約定還可以規範更小的細節，例如縮進。想像一下，如果縮進不一致，版本控制將變成一場徹頭徹尾的噩夢，一些人使用製表符而另一些人使用空格。對於需要僅通過一種方法簽入修復程序但發現整個文件由於空格和製表符的差異而發生更改的人來說會是什麼樣子？當然，與普通語言一樣，慣例可能會根據語言的使用位置而改變。例如，在浩瀚的網絡中，您可以找到Google Java Style Guide和Twitter Java Style Guide. 對於這次審查，我們需要一個測試對象。我們將使用 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 testSumOfOddNumbers() {
 	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在 IDEA 菜單中（或按 Ctrl+Alt+S）。在設置窗口的搜索字段中輸入“代碼樣式”。在“代碼風格”部分，您可以為更多語言指定設置，而不僅僅是 Java。但 Java 是我們現在感興趣的。如您所見，設置分為幾個選項卡。一個超級有用的功能是窗口右側顯示了一個操作示例： 屏幕截圖顯示我們可以將“鍊式方法調用”設置為“始終包裝”，即始終將鍊式方法調用拆分為單獨的行。現在在測試類中再次點擊格式化按鈕，我們看到它真的起作用了！但有時您需要在標準格式化規則之外格式化一些代碼。設置格式如下： 為了防止格式化，在“代碼風格”部分，啟用格式化程序標記： 現在我們可以更改我們的測試類，這樣它的代碼就不會被重新格式化：

 @Test
 public void testSumOfOddNumbers() {
 	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 將其解釋為一個空格（這是默認行為）。但是您可以在“”部分更改它Code Style： 如您所見，那裡有很多設置。您可以在此處閱讀有關“”設置的更多詳細信息Code style：“ IDEA 幫助：代碼樣式”。還有另一個重要的格式化功能：格式化導入。此操作單獨運行，稱為“ Optimize Imports”。它位於Code -> Optimize Imports(Ctrl+Alt+O) 下。優化導入刪除不必要的導入，並根據Java 設置的Imports“”選項卡中的設置以正確的順序排列導入。Code Style更重要的是，如果您希望自動進行這種格式化，那麼有個好消息：保存動作插件。

在命令中分發設置

我們在上面看到，您可以隨心所欲地自定義格式樣式。但是你如何在團隊中使用這種風格呢？非常簡單地。有幾種選擇。最簡單的就是保存一個代碼風格方案。File -> Settings使用（或按 Ctrl+Alt+S）打開 IDEA 設置。在“ Code Style”部分，我們可以看到“Scheme”。這是我們的格式化方案。默認情況下，使用“默認”方案並標記為“IDE”，這意味著此設置僅適用於我們的 IDE——它不會影響任何其他人。要製作“自定義”方案，請使用右側的按鈕製作副本並為其命名，例如：CodeGym 然後我們可以導入或導出設置： 另一種選擇是導入 IDEA 設置： 第三個選項是設置存儲庫。要使用 Settings Repository，請參閱以下鏈接中的 IntelliJ IDEA 幫助文檔以獲取更多詳細信息：“ Settings Repository ”。說到在團隊中推動統一樣式，我也不得不提到 Eclipse 對樣式的良好支持IDE。為此，您需要安裝一個單獨的插件：通過“文件”->“設置”(Ctrl+Alt+S) 打開 IDEA 設置，然後轉到“插件”部分。要查找新插件，請單擊“”按鈕。Browse Repositories然後在搜索窗口中找到 Eclipse Code Formatter 插件。 安裝後，您必須重新啟動 IDEA——這是標準程序。現在一切都完成了。IDEA 設置中有一個新部分：“Eclipse Code Formatter”。. 它看起來像這樣：

更嚴格的要求

除了 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

轉到報告，我們看到類似這樣的內容： 此外，“ Problem”列提供指向 pmd 插件網站上問題描述的鏈接。例如，對於“ headerCommentRequirement Required”錯誤，鏈接位於此處：pmd — CommentRequired。這個錯誤提示我們的類沒有 JavaDoc。我們可以使用模板在類上面配置一個 JavaDoc： 並指定內容File Header： 之後，我們可以將 App 類上面的註釋變成一個 JavaDoc，然後在新的構建中看到錯誤消失了。

底線

代碼風格對於最大化項目生產力很重要。根據共享規則編寫的優美代碼可確保您的同事更容易、更快速地理解它，並且不會對您提出一大堆批評。使用現代開發工具，遵守樣式規則並不難。我希望這篇評論向您證明這是真的。按照傳統，這裡有一些關於該主題的額外材料：

• 來自 JetBrainsTV 的視頻：“檢查代碼 (IntelliJ IDEA) ”
• 回顧“使用 Gradle 插件進行代碼分析”
• “自動化代碼質量”課程