IntelliJ IDEA: Stilul de codare și formatarea codului

Un limbaj de programare este foarte asemănător cu un limbaj vorbit. Singura diferență este că este un limbaj special al cărui scop principal este de a facilita comunicarea cu un computer pentru a explica computerului ce vrem să facă. Dar nu poți avea o conversație personală cu un computer. Când ai început să înveți un limbaj de programare, te-ai uitat la cărți sau la o resursă educațională precum CodeGym. Și această resursă ți-a arătat un cod pe care computerul îl înțelege. Dar și tu ar trebui să-l înțelegi pe măsură ce înveți despre limbajul Java. Ca în orice limbaj, în programare au fost adoptate unele convenții de formatare. De exemplu, în societatea politicoasă, a scrie așa ar fi considerat proaste maniere. Și în Java, începerea numelui unei metode cu o literă mare este o încălcare gravă a convențiilor de codare. Regulile pentru codul Java sunt date în documentul Convenții de cod pentru limbajul de programare Java . Convențiile de codificare pot reglementa și detalii mai mici, cum ar fi indentarea. Imaginați-vă coșmarul absolut în care ar deveni controlul versiunilor dacă indentarea ar fi inconsecventă, unii oameni folosind file și alții folosind spații. Cum ar fi pentru cineva care trebuie să verifice o remediere într-o singură metodă, dar găsește că întregul fișier a fost schimbat din cauza diferențelor de spații și file? Desigur, ca și în cazul limbajului obișnuit, convențiile se pot schimba în funcție de locul în care este folosită o limbă. De exemplu, în vastele întinderi ale webului, puteți găsi Ghidul de stil Google Java și Ghidul de stil Twitter Java. Pentru această revizuire, avem nevoie de un subiect de testare. Vom folosi sistemul de automatizare a construcției Gradle. Ne va permite să începem rapid prin crearea unui nou proiect dintr-un șablon. Gradle are un plugin grozav: Build Init Plugin . Să mergem la un nou director și să rulăm următoarea comandă acolo: gradle init --type java-application După aceea, porniți IntelliJ IDEA. Dacă vedeți o fereastră cu un proiect deschis (adică vedeți editorul de cod și arborele de proiect), închideți acest proiect folosind File -> Close Project. Acum, în fereastra de bun venit, rulați „ Import Project” și importați noul nostru proiect. Când importați, setați Use autoimportcaseta de selectare " ". Să ne dăm seama dacă putem folosi instrumente de dezvoltare de ultimă generație pentru a simplifica cumva viața.

Formatarea codului în IDEA

După importarea proiectului, apăsați Ctrl+N și mergeți la AppTestclasă. Aceasta este clasa de testare implicită. Arata cam asa:

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());
    }
}

Ce vă atrage imediat atenția? O adnotare pe aceeași linie cu o declarație de metodă, care arată urât, nu? Cum să remediez asta? IntelliJ IDEA are o Codeintrare în meniu " " pentru diverse manipulări de cod. O astfel de manipulare este " Reformat Code", pe care o puteți aplica folosind Ctrl+L. După ce faceți acest lucru, adnotarea va fi pe o linie, iar declarația metodei pe alta. Este demn de remarcat imediat că această operațiune este efectuată pe codul selectat în prezent . Dacă nu există nicio selecție, atunci operația de formatare este efectuată pe tot. Acum să adăugăm o nouă metodă de testare:

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

Și două importuri:

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

După cum puteți vedea, operațiunea pe Stream este pe o singură linie. Dar dacă vrem să ne asigurăm că apelurile de metodă înlănțuite sunt întotdeauna împărțite în linii noi la fiecare operator de perioadă? Am putea face asta manual. Dar amintiți-vă că vrem ca totul să se întâmple automat. Într-adevăr, cu siguranță vom uita din când în când pasul manual și apoi vom ajunge cu o formatare diferită peste tot și asta nu este bine. Deci trebuie să edităm regula pe care IDEA o folosește pentru formatare. AlegeFile -> Settingsîn meniul IDEA (sau apăsați Ctrl+Alt+S). Introduceți „Stil cod” în câmpul de căutare din fereastra de setări. În secțiunea „Stil de cod”, puteți specifica setări pentru mai multe limbi decât Java. Dar Java este ceea ce ne interesează acum. După cum puteți vedea, setările sunt împărțite în mai multe file. O caracteristică super utilă este că un exemplu de operație este afișat în partea dreaptă a ferestrei: Captura de ecran arată că putem seta „Apeluri de metodă înlănțuite” la „încheierea întotdeauna”, adică întotdeauna împărțiți apelurile de metodă înlănțuite în linii separate. Acum faceți clic din nou pe butonul de formatare în clasa de testare și vedem că funcționează cu adevărat! Dar uneori trebuie să formatați un cod în afara regulilor standard de formatare. Configurați formatarea după cum urmează: Pentru a preveni formatarea, în secțiunea „Stil cod”, activați marcatorii de formatare: Acum putem schimba clasa noastră de testare, astfel încât codul său să nu fie reformatat:

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

Poate ați observat că atunci când apăsați Tab, IDEA îl interpretează ca un spațiu (acesta este comportamentul implicit). Dar puteți schimba acest lucru în Code Stylesecțiunea „ ”: După cum puteți vedea, există o mulțime de setări acolo. Puteți citi mai multe detalii despre Code stylesetările " " aici: " IDEA Help: Code Style ". Există o altă caracteristică importantă de formatare: formatarea importurilor. Această operațiune se execută separat și se numește " Optimize Imports". Este situat sub Code -> Optimize Imports(Ctrl+Alt+O). Optimizarea importurilor elimină importurile inutile și aranjează importurile în ordinea corectă, conform setărilor din Importsfila " " din Code Stylesetările " " pentru Java. În plus, dacă doriți ca această formatare să aibă loc automat, există o veste bună:Pluginul Save Actions .

Distribuirea setărilor într-o comandă

Am văzut mai sus că vă puteți personaliza stilul de formatare după cum doriți. Dar cum folosești acest stil în cadrul unei echipe? Foarte usor. Există mai multe opțiuni. Cel mai simplu este să salvați o schemă de stil de cod. Deschideți setările IDEA folosind File -> Settings(sau apăsați Ctrl+Alt+S). În Code Stylesecțiunea „ ” putem vedea „Schema”. Aceasta este schema noastră de formatare. În mod implicit, schema „Default” este utilizată și este etichetată „IDE”, ceea ce înseamnă că această setare se aplică numai IDE-ului nostru – nu afectează pe nimeni altcineva. Pentru a face o schemă „personalizată”, folosiți butonul din dreapta pentru a face o copie și a-i da un nume, de exemplu: CodeGym Apoi că putem importa sau exporta setările: O altă opțiune este să importam setările IDEA: O a treia opțiune este Depozitul de setări. Pentru a utiliza Depozitul de setări, consultați documentația de ajutor IntelliJ IDEA pentru mai multe detalii la următorul link: Depozitul de setări ". Vorbind despre promovarea unui stil unificat într-o echipă, nu pot să nu menționez suportul bun pentru stilurile din Eclipse. IDE. Pentru a face acest lucru, trebuie să instalați un plugin separat: deschideți setările IDEA prin Fișier -> Setări (Ctrl+Alt+S) și mergeți la secțiunea „Plugin-uri". Pentru a găsi plugin-uri noi, faceți clic pe butonul " ". Browse RepositoriesApoi găsiți pluginul Eclipse Code Formatter în fereastra de căutare. După ce îl instalați, va trebui să reporniți IDEA — aceasta este procedura standard. Acum totul este gata. Există o nouă secțiune în setările IDEA: „Eclipse Code Formatter”.. Va arata cam asa:

Cerințe mai stricte

În plus față de instrumentele IDEA, puteți folosi și pluginuri de automatizare pentru a înăspri cerințele. Nu există nicio modalitate de a verifica manual dacă cineva a folosit formatarea corectă. Poate ai putea cu 5 oameni într-o echipă. Dar cu 100 de oameni la o companie, nu este realist. Și chiar și cinci vor fi greu de urmărit. Și de ce să-ți pierzi timpul cu toate astea? Ar fi mult mai ușor să împiedicăm construirea proiectului dacă regulile sunt încălcate. De fapt, acesta este un subiect complet separat numit „Inspectați codul”. În acest articol, vreau doar să vă arăt cum funcționează. Unul dintre cele mai populare plugin-uri Gradle (pentru că ne construiește proiectul, vă veți aminti) este pmd. Pentru a-l activa, accesați scriptul de compilare al proiectului Gradle (fișierul build.gradle de la rădăcina proiectului nostru) și adăugați pmd lângă restul pluginurilor:

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

Acum putem introduce setări mai detaliate în același loc:

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'
    ]
}

Chiar și proiectul nostru este stricat acum. Rulați gradle buildși primim o eroare. Lucrul frumos este că un raport este generat în timpul construirii. Și dacă există erori, primim un mesaj ca acesta:

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

Mergând la raport, vedem ceva de genul acesta: Mai mult, coloana „ Problem” oferă un link către o descriere a problemei pe site-ul pluginului pmd. De exemplu, pentru eroarea " headerCommentRequirement Required", linkul merge aici: pmd — CommentRequired . Această eroare este un indiciu că clasa noastră nu are un JavaDoc. Putem folosi șabloane pentru a configura un JavaDoc deasupra claselor: Și să specificăm conținutul pentru File Header: După aceea, putem transforma comentariul de deasupra clasei App într-un JavaDoc și să vedem că eroarea a dispărut într-o nouă versiune.

Linia de jos

Stilul codului este important pentru a maximiza productivitatea unui proiect. Un cod frumos scris în conformitate cu regulile comune garantează că colegii tăi îl vor înțelege mai ușor și mai rapid și nu îți va da o ureche de critici. Cu instrumentele moderne de dezvoltare, nu este atât de greu să respectați regulile de stil. Sper că această recenzie ți-a dovedit că acest lucru este adevărat. Urmând tradiția, iată un mic material suplimentar pe această temă:

• Videoclip de la JetBrainsTV: „ Inspectați codul (IntelliJ IDEA) ”
• Revizuirea „ Analiza codului cu pluginuri Gradle ”
• Curs „ Automatizați calitatea codului ”.