IntelliJ IDEA: стиль та форматування коду

Сучасні інструменти дозволяють спростити процес розробки. У тому числі легше стежити за стилем свого коду, намагаючись зводити до мінімуму його "самовільне" форматування. У цьому огляді пропоную ознайомитися з тим, які кошти надає IDE IntelliJ Idea розробнику для того, щоб код було приємно читати та легко розуміти.

Вступ

Мова програмування дуже схожа на мову, якою розмовляють люди. Різниця лише в тому, що це особлива мова, яка спочатку служить для спілкування з комп'ютером, щоб пояснити, що ми від нього хочемо. Але спілкування віч-на-віч з комп'ютером не може бути. Навіть коли ви починали вивчати мову програмування, ви дивабося в книгу або якийсь освітній ресурс на кшталт JavaRush. І в цьому джерелі ви бачабо код, який зрозуміє комп'ютер. Але і ви повинні розуміти його в міру того, як у вас з'являється знання Java мови. Як і будь-якою мовою, у програмуванні прийнято деякі правила формування коду. Наприклад, писати заборомв пристойному суспільстві вважатиметься правилом поганого тону, а Java називати метод з великої літери є грубим порушенням code style. Правила оформлення Java коду сформульовані у документі Java Code Convention . Крім того, стиль оформлення коду може регламентувати і дрібніші деталі, наприклад, відступи. А коли використовуються засоби контролю версій, уявіть собі весь кошмар, коли кожен зберігатиме файл то з відступами у вигляді tab, то з відступами у вигляді пробілів. Яке буде тому, кому треба перевірити редагування всього в одному методі, а змінено буде весь файл через виправлення пробілів на таби або навпаки. Звичайно, як і зі звичайною мовою, стиль може змінюватися в залежності від місця, де він використовується. Наприклад, на просторах мережі можна знайти 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 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 виконує форматування. Виберемо в Idea в меню пункт File -> Settings(або натиснемоCtrl + Alt + S). У полі пошуку у вікні налаштувань напишемо "Code style". У розділі Code style можна вказати налаштування не тільки для Java. Але зараз нас цікавить саме Java. Як видно, параметри розбиті на кілька вкладок. Що найкорисніше, так це те, що результат зміни буде показаний на прикладі у правій частині вікна: Як бачимо на скріншоті, ми можемо вказати налаштування для "Chained method calls" як "wrap always", тобто. завжди розбивати для об'єднаних викликів методів. Тепер натиснемо ще раз форматування у тесті та побачимо, що це дійсно працює! Але іноді буває, що є потреба відформатувати якийсь код поза загальними правилами форматування. Налаштуємо форматування так: Щоб форматування можна було відключати, у розділі Code Style необхідно увімкнути підтримку маркерів відключення форматування: Тепер ми зможемо змінити код нашого тесту так, що його форматування залишиться в тому вигляді, в якому це ми напишемо:

@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 за вас його інтерпретує як прогалини (за замовчуванням поведінка). Але змінити це можна там же у Code Style: Як Ви бачите, там безліч налаштувань. Докладніше про налаштування Code style можна прочитати тут: " Idea Help: Code Style ". Є ще одна важлива особливість форматування – форматування імпортів. Воно виконується окремо і називається "Optimize Imports"і знаходиться у пункті меню Code -> Optimize Imports(Ctrl+Alt+O). Оптимізація імпорту прибирає непотрібні імпорти, а також розташовує їх у правильному порядку відповідно до налаштувань із вкладки Imports налаштувань Code Style для Java. Крім того, якщо ви захочете, щоб форматування відбувалося автоматично, для вас є хороша новина: це можна зробити за допомогою плагіна Save Actions .

Поширення налаштувань у команді

Відмінно, ми побачабо, що можна налаштувати стиль форматування так, як нам зручно. Але як цей стиль використовувати у команді? Дуже просто. Є кілька варіантів. Найпростіший – зберегти схему. Відкриємо налаштування Idea через File->Settings (або натиснемо Ctrl+Alt+S). У розділі Code Style ми можемо побачити напис Scheme. Це наша схема форматування. За замовчуванням вказана схема з ім'ям Default та поруч приписка IDE: це означає, що це налаштування тільки для нашої IDE, і вона не діє ні на кого. Щоб зробити "користувацьку" схему, по кнопці праворуч робимо "дублікат" і даємо йому назву, наприклад: JavaRush Після цього ми зможемо імпортувати або експортувати налаштування: Інший варіант - це імпорт імпорту налаштувань Idea: Третій варіант - Settings Repository. Для використання Settings Repository див. докладніше документацію "IntelliJ Idea Help: Settings Repository ". У тему поширення єдиного стилю у команді також не можу не відзначити хорошу підтримку стилів із IDE Eclipse. Для цього потрібно встановити окремий плагін: відкрийте налаштування Idea через File -> Settings (Ctrl + Alt + S) і перейдіть в розділ Plugins. Для пошуку нових плагінів натисніть кнопку "Browse Repositories", після чого у вікні пошуку знайдемо плагін Eclipse Code Formatter. Тепер, після встановлення, необхідно перезапустити Idea – це стандартна процедура. Після цього, все там же, в налаштуваннях Idea, ми знайдемо новий розділ: "Eclipse Code Formatter" Приклад файлу форматування для Eclipse можна взяти тут . Виглядатиме це приблизно так:

Посилення вимог

Крім засобів Idea, можна також використовувати плагіни систем збирання для посилення вимог. Ніяк не перевіриш, що людина використовувала форматування. Якщо в команді 5 осіб – ще можна. Якщо в компанії 100 осіб – нереально. Та навіть за п'ятьма встежити буде важко. Та й навіщо зайва трата часу на таке? Набагато простіше заборонити збирати проект при порушенні деяких правил. Насправді це вже ціла окрема тема під назвою "Inspect Code". У рамках цієї статті хочеться просто показати як це працює. Одним з найпоширеніших плагінів для Gradle (бо він збирає у нас проект, якщо пам'ятаєте) є pmd . Для його включення достатньо перейти в build script нашого 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 і побачимо при новому Build, що помилка зникла.

Підсумок

Стиль коду важливий для роботи над проектом. Гарний код, написаний за загальними правилами - запорука того, що ваші колеги його простіше і швидше зрозуміють, і не скажуть на вашу адресау пари ласкавих. Враховуючи сучасні засоби розробки, дотримуватися правил не так вже й складно. Сподіваюся, цей огляд показав, що це справді так. Ну і за традицією, небагато матеріалу на тему:

• Відео від JetBrainsTV: " Inspect Code (IntelliJ IDEA) "
• Огляд " Code Analysis With Gradle Plugins "
• Курс " Automate Code Quality "

#Viacheslav