IntelliJ IDEA: Стил на кодиране и форматиране на кода

Езикът за програмиране е много подобен на говоримия език. Единствената разлика е, че това е специален език, чиято основна цел е да улесни комуникацията с компютър, за да обясни на компютъра Howво искаме да прави. Но не можете да водите личен разговор с компютър. Когато сте започнали да изучавате език за програмиране, сте разглеждали книги or няHowъв образователен ресурс като CodeGym. И този ресурс ви показа code, който компютърът разбира. Но вие също трябва да го разберете, когато научите за езика Java. Както при всеки език, в програмирането са приети някои конвенции за форматиране. Например, в учтиво общество, ПИСАНЕТО КАТО ТОВА ще се счита за лошо възпитание. А в Java започването на име на метод с главна буква е грубо нарушение на конвенциите за codeиране. Правилата за Java code са дадени в documentа Кодови конвенции за езика за програмиране Java . Конвенциите за codeиране също могат да регулират по-малки детайли, като отстъп. Представете си пълния кошмар, в който би се превърнал контролът на версиите, ако отстъпът е непоследователен, някои хора използват раздели, а други хора използват интервали. Какво би било за някой, който трябва да провери корекция само с един метод, но намира целия файл променен поради разлики в интервалите и разделите? Разбира се, Howто при обикновения език, конвенциите могат да се променят в зависимост от това къде се използва даден език. Например в необятните пространства на мрежата можете да намерите Ръководство за стил на Google Java и Ръководство за стил на Twitter за Java. За този преглед се нуждаем от тестов обект. Ще използваме системата за автоматизация на изграждане на Gradle. Това ще ни позволи да започнем бързо, като създадем нов проект от шаблон. Gradle има страхотен плъгин: Build Init Plugin . Нека отидем в нова директория и изпълним следната команда там: gradle init --type java-application След това стартирайте IntelliJ IDEA. Ако видите прозорец с отворен проект (т.е. виждате редактора на codeа и дървото на проекта), затворете този проект, като използвате File -> Close Project. Сега в прозореца за добре дошли стартирайте „ Import Project“ и импортирайте нашия нов проект. Когато импортирате, поставете Use autoimportотметка в квадратчето „ “. Нека да разберем дали можем да използваме най-съвременните инструменти за разработка, за да опростим по няHowъв начин живота.

Форматиране на code в 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" запис в менюто за различни манипулации на codeа. Една такава манипулация е " Reformat Code", която можете да приложите с помощта на Ctrl+L. След като направите това, анотацията ще бъде на един ред, а декларацията на метода на друг. Заслужава да се отбележи веднага, че тази операция се извършва върху текущо избрания code . Ако няма избор, тогава операцията по форматиране се извършва върху всичко. Сега нека добавим нов тестов метод:

 @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;

Както можете да видите, операцията на потока е на един ред. Но Howво ще стане, ако искаме да сме сигурни, че верижните извиквания на метод винаги се разделят на нови редове при всеки оператор за период? Можем да направим това ръчно. Но не забравяйте, че искаме всичко да се случва автоматично. Наистина със сигурност ще забравяме ръчната стъпка от време на време и тогава ще се окажем с различно форматиране навсякъде, а това не е добре. Така че трябва да редактираме правилото, което IDEA използва за форматиране. ИзбирамFile -> Settingsв менюто IDEA (or натиснете Ctrl+Alt+S). Въведете „Стил на codeа“ в полето за търсене в прозореца с настройки. В секцията „Стил на codeа“ можете да зададете настройки за повече езици, освен само за Java. Но Java е това, което ни интересува в момента. Както можете да видите, настройките са разделени на няколко раздела. Супер полезна функция е, че в дясната част на прозореца е показан пример за операцията: Екранната снимка показва, че можем да зададем "Chained method calls" на "wrap always", т.е. винаги да разделяме верижните извиквания на метод на отделни редове. Сега щракнете отново върху бутона за форматиране в тестовия клас и виждаме, че наистина работи! Но понякога трябва да форматирате няHowъв code извън стандартните правила за форматиране. Настройте форматирането, Howто следва: За да предотвратите форматирането, в секцията „Стил на codeа“ активирайте маркерите за форматиране: Сега можем да променим нашия тестов клас, така че неговият code да не се преформатира:

 @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: Стил на codeа “. Има още една важна функция за форматиране: форматиране на импортирания. Тази операция се изпълнява отделно и се нарича " Optimize Imports". Намира се под Code -> Optimize Imports(Ctrl+Alt+O). Оптимизирането на импортирането премахва ненужното импортиране и подрежда импортирането в правилния ред според настройките в Importsраздела „ “ на Code Styleнастройките „ “ за Java. Нещо повече, ако искате това форматиране да се случи автоматично, има добри новини:Плъгин за запазване на действия .

Разпределяне на настройки в команда

Видяхме по-горе, че можете да персонализирате своя стил на форматиране, Howто искате. Но How използвате този стил в екип? Много лесно. Вариантите са няколко. Най-простият е да запазите схема на стил на code. Отворете настройките на IDEA, като използвате File -> Settings(or натиснете Ctrl+Alt+S). В Code Styleсекцията " " можем да видим "Схема". Това е нашата схема за форматиране. По подразбиране се използва схемата „По подразбиране“ и е означена с „IDE“, което означава, че тази настройка се отнася само за нашата IDE — не засяга никой друг. За да направите "персонализирана" схема, използвайте бутона вдясно, за да направите копие и да му дадете име, например: CodeGym След това можем да импортираме or експортираме настройките: Друга опция е да импортирате IDEA настройки: Трета опция е хранorщето на настройките. За да използвате хранorщето за настройки, вижте documentацията за помощ на IntelliJ IDEA за повече подробности на следната връзка: Хранorще за настройки ". Говорейки за налагане на унифициран стил в екип, не мога да не спомена добрата поддръжка за стилове от Eclipse IDE. За да направите това, трябва да инсталирате отделен плъгин: отворете настройките на IDEA чрез Файл -> Настройки (Ctrl+Alt+S) и отидете в секцията „Приставки“. За да намерите нови приставки, щракнете върху бутона „ “. След Browse Repositoriesтова намерете плъгина Eclipse Code Formatter в прозореца за търсене. След като го инсталирате, ще трябва да рестартирате IDEA — това е стандартна proceduresа. Сега всичко е готово. Има нов раздел в настройките на IDEA: „Eclipse Code Formatter“.. Ще изглежда нещо подобно:

По-строги изисквания

В допълнение към инструментите IDEA, можете също да използвате добавки за автоматизация на изграждането, за да затегнете изискванията. Няма начин да проверите ръчно дали някой е използвал правилно форматиране. Може би бихте могли с 5 души в екип. Но със 100 души в една компания това не е реалистично. И дори пет ще бъдат трудни за проследяване. И защо да си губите времето с всичко това? Би било много по-лесно да се предотврати изграждането на проекта, ако правилата са нарушени. Всъщност това е цяла отделна тема, наречена "Проверете codeа". В тази статия просто искам да ви покажа How работи. Един от най-популярните плъгини за 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 — Изисква се коментар . Тази грешка е намек, че нашият клас няма JavaDoc. Можем да използваме шаблони, за да конфигурираме JavaDoc над класове: И да посочим съдържанието за File Header: След това можем да превърнем коментара над класа на приложението в JavaDoc и да видим, че грешката е изчезнала в нова компилация.

Долния ред

Стилът на codeа е важен за максимизиране на производителността на даден проект. Красивият code, написан според споделени правила, гарантира, че колегите ви ще го разберат по-лесно и бързо и няма да ви критикуват. С модерните инструменти за разработка не е толкова трудно да се придържате към стиловите правила. Надявам се, че този преглед ви е доказал, че това е вярно. Следвайки традицията, ето малко допълнителен материал по темата:

• Видео от JetBrainsTV: " Проверете codeа (IntelliJ IDEA) "
• Преглед на „ Анализ на code с приставки за Gradle “
• Курс „ Автоматизиране на качеството на codeа “.