IntelliJ IDEA: Код стили жана форматтоо

Заманбап шаймандар иштеп чыгуу процессин жеңилдетет. Атап айтканда, codeуңуздун стorн көзөмөлдөө оңой, анын "уруксатсыз" форматтоосун азайтуу аракети. Бул кароодо мен IntelliJ Idea IDE иштеп чыгуучуга codeду окууга жагымдуу жана түшүнүктүү кылуу үчүн кандай куралдар менен таанышууну сунуштайм.

Киришүү

Программалоо тor адамдар сүйлөгөн тилге абдан окшош. Бир гана айырмасы - бул компьютерден эмнени каалап жатканыбызды түшүндүрүү үчүн алгач компьютер менен байланышуу үчүн колдонулган атайын тил. Бирок компьютер менен жекеме-жеке байланыш болушу мүмкүн эмес. Сиз программалоо тorн үйрөнүп баштаганыңызда да, сиз китепти же JavaRush сыяктуу бorм берүүчү булакты карадыңыз. Жана бул булакта сиз компьютер түшүнө турган codeду көрдүңүз. Бирок сиз Java тorн билүү үчүн аны түшүнүшүңүз керек. Бардык тилдердегидей эле, программалоодо codeду түзүүнүн кээ бир эрежелери бар. Мисалы, сылык коомдо тосмо менен жазуу жаман адеп деп эсептелет, ал эми Javaда баш тамга менен ыкманы чакыруу code стorн одоно бузуу болуп саналат. Java codeун форматтоо эрежелери Java Code Convention documentинде формулировкаланган . Мындан тышкары, code стor чегинүү сыяктуу майда деталдарды жөнгө сала алат. Ал эми versionны башкаруу куралдары колдонулганда, ар бир адам өтмөк катары чегинген же боштук катары чегилген файлды сактаганда, бүт коркунучтуу кыялды элестетиңиз. Түзөтүүнү бир эле ыкма менен текшериши керек болгон адам үчүн бул кандай болот, бирок өтмөктөрдөгү боштуктарды оңдоодон улам бүт файл өзгөрөт же тескерисинче. Албетте, кадимки тил сыяктуу эле, стor колдонулган жерине жараша өзгөрүшү мүмкүн. Мисалы, Интернетте сиз таба аласыз Google Java Style Guide же Twitter Java Style Guide . Бул карап чыгуу макала үчүн, биз сыноо предмети керек болот. Келгиле, Gradle долбоору куруу системасынын кызматын колдонолу. Бул бизге тез баштоо үчүн шаблонду колдонуу менен жаңы долбоорду түзүүгө мүмкүндүк берет. Gradleде сонун плагин бар: Build Init Plugin . Келгиле, жаңы каталогго барып, ошол жерден буйрукту аткаралы: gradle init --type java-application Андан кийин IntelliJ Idea программасын ишке киргизиңиз. Эгер сиз мурунтан эле ачылган долбоору бар терезени көрсөңүз (сиз code редакторун, долбоордун структурасынын дарагын көрөсүз), бул долбоорду колдонуп жабыңыз File -< Close Project. Эми саламдашуу терезесинде биз "Import Project"жаңы долбоорду ишке ашырабыз жана импорттойбуз. Импорттоодо желекти коюңуз "Use autoimport". Заманбап өнүгүү куралдарынын жардамы менен жашоону кандайдыр бир жол менен жөнөкөйлөтүү мүмкүнбү, жокпу, карап көрөлү.

Идеядагы codeду форматтоо

Долбоорду импорттоодон кийин, баскыч айкалышын басып 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());
    }
}

Бул жерде эмне дароо көзүңүзгө урунду? Бир сапта метод декларациясы бар annotation, көрксүз көрүнгөн, макул. Муну кантип оңдоо керек? IntelliJ Idea ар кандай codeдук манипуляциялар үчүн меню бөлүмү бар "Code". Мындай манипуляциялардын бири - "Reformat Code"негизги айкалышы Ctrl + L. Колдонмодон кийин annotation бир сапта, ал эми методдун өзү башка сапта болот. Бул операция codeдун тандалган бөлүгүндө аткарылганын дароо белгилей кетүү керек . Ал эми мындай нерсе жок болсо, форматтоо операциясы бардык мазмунда аткарылат. Эми жаңы сыноо ыкмасын кошолу:

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

Көрүнүп тургандай, Агымдагы операция бир сапта жайгаштырылган. Бирок, эгер биз чакырыктары чынжырланган ыкмалар ар дайым жаңы саптарга бөлүнгөнүнө ынангыбыз келсечи? Бир жагынан, биз муну кол менен жасай алабыз. Бирок биз бардыгы биз үчүн иштешин каалай турганыбызды унутпаңыз. Анткени, мезгил-мезгor менен биз унутуп калабыз, ал эми code форматы бардык жерде ар кандай болуп калат, бул жакшы эмес. Көрсө, сиз Idea форматтоочу эрежени түзөтүшүңүз керек экен. Менюдан Идея пунктун тандаңыз File -> Settings(же чыкылдатыңыз Ctrl + Alt + S). Орнотуулар терезесиндеги издөө талаасында "Код стor" деп жазыңыз. Код стor бөлүмүндө бир гана Java үчүн эмес, орнотууларды көрсөтүүгө болот. Бирок азыр биз Javaга кызыгып жатабыз. Көрүнүп тургандай, орнотуулар бир нече өтмөккө бөлүнгөн. Эң пайдалуу нерсе, өзгөртүүнүн натыйжасы терезенин оң жагындагы мисалда көрсөтүлөт: Скриншоттон көрүнүп тургандай, биз "Чынжырланган ыкма чалуулары" үчүн жөндөөнү "ар дайым ороп коюу" деп белгилей алабыз, б.а. ар дайым бириктирилген ыкма чалуулары үчүн бөлүнөт. Эми тестте форматтоону дагы бир жолу басып, анын чындап иштегенин көрөлү! Бирок кээде жалпы форматтоо эрежелеринен тышкары кандайдыр бир codeду форматтоо зарылчылыгы келип чыгат. Келиңиз, форматтоону төмөнкүдөй орнотобуз: Форматтоону өчүрүү үчүн, форматтоо маркерлерин өчүрүү үчүн колдоо Code Style бөлүмүндө иштетorши керек: Эми биз тесттин codeун өзгөртө алабыз, анын форматы биз жазган формада кала берет:

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

Ооба, эгер байкасаңыз: Табакты басканда, Idea аны сиз үчүн боштук катары чечмелейт (демейки жүрүм-турум). Бирок сиз муну code стorнде өзгөртө аласыз: Көрүнүп тургандай, орнотуулардын ар кандай түрлөрү бар. Код стorнин жөндөөлөрү тууралуу кененирээк бул жерден окуй аласыз: " Idea Help: Code Style ". Дагы бир маанилүү форматтоо өзгөчөлүгү бар - импорттоо форматтоо. Ал өзүнчө аткарылат жана чакырылат "Optimize Imports"жана меню пунктунда жайгашкан Code -> Optimize Imports(Ctrl + Alt + O). Импортту оптималдаштыруу керексиз импортту жок кылат, ошондой эле аларды Java орнотуулары үчүн code стorнин Импорттоо өтмөгүндөгү орнотууларга ылайык туура иретке келтирет. Ошондой эле, эгер сиз форматтоо автоматтык түрдө болушун кааласаңыз, жакшы жаңылык, сиз муну Save Actions плагини аркылуу жасай аласыз .

Командага орнотууларды бөлүштүрүү

Абдан жакшы, биз жогоруда биз форматтоо стorн өзүбүзгө ылайыкташтыра аларыбызды көрдүк. Бирок бул стилди командада кантип колдонсо болот? Өтө жөнөкөй. Бир нече варианттар бар. Эң оңойсу - диаграмманы сактоо. Файл -> Орнотуулар аркылуу идея орнотууларын ачыңыз (же Ctrl + Alt + S баскычтарын басыңыз). Code Style бөлүмүндө биз жазуу схемасын көрө алабыз. Бул биздин форматтоо схемабыз. Демейки боюнча, схема Демейки аталышы менен көрсөтүлөт жана анын жанында IDE annotationсы болот: бул бул жөндөө биздин IDE үчүн гана экенин жана ал эч кимге таасирин тийгизбейт дегенди билдирет. "Ыңгайлаштырылган" схеманы түзүү үчүн, "дубликат" кылуу үчүн оң жактагы баскычты чыкылдатып, ага ат бериңиз, мисалы: JavaRush Андан кийин биз орнотууларды импорттоо же экспорттоо мүмкүнчүлүгүнө ээ болобуз: Дагы бир вариант - Idea орнотууларын импорттоо: Үчүнчү параметр - Орнотуулар репозиторий. Орнотуулар репозиторийин колдонуу боюнча көбүрөөк маалымат алуу үчүн "IntelliJ Idea Жардам: Орнотуулар Репозиторий " documentациясын караңыз . Командада бирдиктүү стилди жайылтуу темасында мен Eclipse IDE стилдеринин жакшы колдоосун белгилебей коё албайм. Бул үчүн сиз өзүнчө плагинди орнотушуңуз керек болот: Файл -> Орнотуулар (Ctrl + Alt + S) аркылуу Idea орнотууларын ачып, Плагиндер бөлүмүнө өтүңүз. Жаңы плагиндерди издөө үчүн баскычты чыкылдатыңыз "Browse Repositories", андан кийин издөө терезесинде Eclipse Code Formatter плагинин табабыз. Эми, орнотулгандан кийин, сиз Ideaны кайра иштетишиңиз керек - бул стандарттуу proceduresа. Андан кийин, ошол эле жерде, Idea жөндөөлөрүндө, биз жаңы бөлүмдү табабыз: "Eclipse Code Formatter". Eclipse үчүн формат файлынын мисалын бул жерден тапса болот . Ал төмөнкүдөй көрүнөт:

Катуу талаптар

Idea куралдарынан тышкары, талаптарды күчөтүү үчүн куруу тутумунун плагиндерин да колдоно аласыз. Адам форматтоо колдонгонун текшерүүнүн эч кандай жолу жок. Командада 5 адам болсо, дагы эле мүмкүн. Эгерде компанияда 100 адам болсо, бул реалдуу эмес. Ооба, бешөөнө да көз салуу кыйын болот. Анан эмнеге буга убакыт коротот? Белгилүү эрежелер бузулса, долбоорду чогултууга тыюу салуу алда канча оңой. Чынында, бул "Текшерүү codeекси" деп аталган бүтүндөй өзүнчө тема. Бул макаланын максаттары үчүн, мен жөн гана анын кантип иштээрин көрсөткүм келет. 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 болушун шаблондор аркылуу конфигурациялоого болот: Жана File Header үчүн мазмунду көрсөтүңүз: Андан кийин, биз App классынын үстүндөгү комментарийди JavaDocка айландыра алабыз жана жаңы Build менен ката жоголуп кеткенин көрө алабыз.

Төмөнкү сызык

Код стor жемиштүү долбоор үчүн маанилүү. Жалпы эрежелерге ылайык жазылган кооз code - бул сиздин кесиптештериңиз аны оңой жана тез түшүнүп, сиз жөнүндө бир нече жылуу сөздөрдү айтпай турганына кепилдик. Заманбап өнүктүрүү куралдарын эске алганда, эрежелерди кармануу анчалык деле кыйын эмес. Бул карап чыгуу чындап эле ушундай экенин көрсөттү деп үмүттөнөм. Ооба, адаттагыдай эле, тема боюнча бир аз материал:

• JetBrainsTV видеосу: " Кодду текшерүү (IntelliJ IDEA) "
• " Gradle Plugins менен codeду талдоо " карап чыгуу
• " Коддун сапатын автоматташтыруу " курсу

#Вячеслав