IntelliJ IDEA: Kodningsstil og kodeformatering

Et programmeringssprog minder meget om et talt sprog. Den eneste forskel er, at det er et særligt sprog, hvis hovedformål er at lette kommunikationen med en computer for at forklare computeren, hvad vi vil have den til at gøre. Men du kan ikke føre en personlig samtale med en computer. Da du begyndte at lære et programmeringssprog, kiggede du på bøger eller en eller anden pædagogisk ressource som CodeGym. Og denne ressource viste dig kode, som computeren forstår. Men du bør også forstå det, når du lærer om Java-sproget. Som med ethvert sprog er nogle formateringskonventioner blevet vedtaget i programmering. For eksempel, i et høfligt samfund vil det at skrive SÅDAN blive betragtet som dårlig manerer. Og i Java er det en grov overtrædelse af kodningskonventionerne at starte en metodes navn med et stort bogstav. Reglerne for Java-kode findes i dokumentet Code Conventions for the Java Programming Language . Kodningskonventioner kan også regulere mindre detaljer, såsom indrykning. Forestil dig det fuldstændige mareridt, som versionskontrol ville blive, hvis indrykning var inkonsekvent, nogle mennesker bruger tabs og andre bruger mellemrum. Hvordan ville det være for en, der har brug for at tjekke en rettelse ind på kun én metode, men finder hele filen ændret på grund af forskelle i mellemrum og tabulatorer? Som med almindeligt sprog kan konventioner naturligvis ændre sig afhængigt af, hvor et sprog bruges. For eksempel kan du på nettets store vidder finde Google Java Style Guide og Twitter Java Style Guide. Til denne anmeldelse har vi brug for en testperson. Vi bruger Gradle build-automatiseringssystemet. Det vil lade os komme hurtigt i gang ved at oprette et nyt projekt fra en skabelon. Gradle har et fantastisk plugin: Build Init Plugin . Lad os gå til en ny mappe og køre følgende kommando der: gradle init --type java-application Start derefter IntelliJ IDEA. Hvis du ser et vindue med et åbent projekt (dvs. du ser kodeeditoren og projekttræet), skal du lukke dette projekt med File -> Close Project. Kør nu " " i velkomstvinduet Import Projectog importer vores nye projekt. Ved import, sæt Use autoimportafkrydsningsfeltet " ". Lad os finde ud af, om vi kan bruge state-of-the-art udviklingsværktøjer til på en eller anden måde at forenkle livet.

Kodeformatering i IDEA

Når du har importeret projektet, skal du trykke på Ctrl+N og gå til klassen AppTest. Dette er standardtestklassen. Det ser sådan ud:

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

Hvad fanger dit øje med det samme? En anmærkning på samme linje som en metodedeklaration, som ser grim ud, ikke? Hvordan fikser man dette? IntelliJ IDEA har en " Code" menuindgang til forskellige kodemanipulationer. En sådan manipulation er " Reformat Code", som du kan anvende ved at bruge Ctrl+L. Når du har gjort dette, vil annoteringen være på én linje, og metodeerklæringen på en anden. Det er værd at bemærke med det samme, at denne handling udføres på den aktuelt valgte kode . Hvis der ikke er noget valg, udføres formateringsoperationen på alt. Lad os nu tilføje en ny testmetode:

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

Og to importer:

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

Som du kan se, foregår operationen på Stream på én linje. Men hvad nu hvis vi vil sikre os, at de kædede metodekald altid opdeles i nye linjer hos hver periodeoperatør? Vi kunne gøre dette manuelt. Men husk, at vi ønsker, at alt skal ske automatisk. Faktisk vil vi helt sikkert glemme det manuelle trin fra tid til anden, og så ender vi med forskellig formatering overalt, og det er ikke godt. Så vi er nødt til at redigere reglen, som IDEA bruger til formatering. VælgeFile -> Settingsi IDEA-menuen (eller tryk på Ctrl+Alt+S). Indtast "Kodestil" i søgefeltet i indstillingsvinduet. I afsnittet "Kodestil" kan du angive indstillinger for flere sprog end blot Java. Men Java er det, vi interesserer os for lige nu. Som du kan se, er indstillingerne opdelt i flere faner. En super nyttig funktion er, at et eksempel på betjeningen vises i højre del af vinduet: Skærmbilledet viser, at vi kan indstille "Chained method calls" til "wrap always", altså altid opdele kædede metodekald i separate linjer. Klik nu på formateringsknappen igen i testklassen, og vi ser, at det virkelig virker! Men nogle gange skal du formatere noget kode uden for standardformateringsreglerne. Indstil formateringen som følger: For at forhindre formatering skal du i afsnittet "Kodestil" aktivere formateringsmarkører: Nu kan vi ændre vores testklasse, så dens kode ikke bliver omformateret:

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

Du har måske bemærket, at når du trykker på Tab, fortolker IDEA det som et mellemrum (dette er standardadfærden). Men du kan ændre dette i Code Styleafsnittet " ": Som du kan se, er der en masse indstillinger der. Du kan læse flere detaljer om " Code style" indstillinger her: " IDEA Help: Code Style ". Der er en anden vigtig formateringsfunktion: formateringsimport. Denne operation køres separat og kaldes " Optimize Imports". Den er placeret under Code -> Optimize Imports(Ctrl+Alt+O). Optimering af import fjerner unødvendige importer og arrangerer importer i den korrekte rækkefølge i henhold til indstillingerne under Importsfanen " " under Code Styleindstillingerne " " for Java. Hvad mere er, hvis du ønsker, at denne formatering skal ske automatisk, er der gode nyheder:Gem handlinger plugin.

Fordeling af indstillinger i en kommando

Vi så ovenfor, at du kan tilpasse din formateringsstil, som du vil. Men hvordan bruger man denne stil inden for et team? Meget nemt. Der er flere muligheder. Det enkleste er at gemme et kodestilskema. Åbn IDEA-indstillinger ved hjælp af File -> Settings(eller tryk på Ctrl+Alt+S). I Code Styleafsnittet " " kan vi se "Scheme". Dette er vores formateringsskema. Som standard bruges "Standard"-skemaet og er mærket "IDE", hvilket betyder, at denne indstilling kun gælder for vores IDE - den påvirker ikke andre. For at lave en "brugerdefineret" ordning, brug knappen til højre for at lave en kopi og give den et navn, for eksempel: CodeGym Så kan vi importere eller eksportere indstillingerne: En anden mulighed er at importere IDEA indstillinger: En tredje mulighed er Indstillinger Repository. For at bruge Settings Repository, se IntelliJ IDEA Help-dokumentationen for flere detaljer på følgende link: Settings Repository ". Når vi taler om at skubbe en samlet stil på et team, kan jeg heller ikke lade være med at nævne den gode support til styles fra Eclipse IDE. For at gøre dette skal du installere et separat plugin: åbn IDEA-indstillinger via Fil -> Indstillinger (Ctrl+Alt+S) og gå til sektionen "Plugins". For at finde nye plugins, klik på knappen " ". Browse RepositoriesDerefter find Eclipse Code Formatter-plugin'et i søgevinduet. Efter installationen skal du genstarte IDEA — dette er standardproceduren. Nu er alt gjort. Der er et nyt afsnit i IDEA-indstillingerne: "Eclipse Code Formatter".. Det kommer til at se sådan ud:

Skærpede krav

Ud over IDEA-værktøjer kan du også bruge build-automatiserings-plugins til at skærpe kravene. Der er ingen måde, du manuelt kan kontrollere, at nogen har brugt korrekt formatering. Måske kunne du med 5 personer på et hold. Men med 100 personer i en virksomhed er det ikke realistisk. Og selv fem vil være svære at spore. Og hvorfor spilde din tid på noget af dette? Det ville være meget nemmere at forhindre projektet i at blive bygget, hvis reglerne overtrædes. Faktisk er dette et helt separat emne kaldet "Inspicer kode". I denne artikel vil jeg bare vise dig, hvordan det fungerer. Et af de mest populære Gradle-plugins (fordi det bygger vores projekt, kan du huske) er pmd. For at aktivere det, skal du blot gå til vores Gradle-projekts build-script (filen build.gradle i roden af ​​vores projekt) og tilføje pmd til det ved siden af ​​resten af ​​plugins:

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

Nu kan vi indtaste mere detaljerede indstillinger samme sted:

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

Selv vores projekt er gået i stykker nu. Løb gradle buildog vi får en fejl. Det gode er, at der genereres en rapport under opbygningen. Og hvis der er fejl, får vi en besked som denne:

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

Når vi går til rapporten, ser vi noget som dette: Desuden Problemgiver kolonnen " " et link til en beskrivelse af problemet på pmd-plugin'ets hjemmeside. For eksempel, for fejlen " headerCommentRequirement Required", går linket her: pmd — CommentRequired . Denne fejl er et hint om, at vores klasse ikke har et JavaDoc. Vi kan bruge skabeloner til at konfigurere et JavaDoc over klasser: Og specificere indholdet for File Header: Derefter kan vi lave kommentaren over App-klassen til et JavaDoc og se, at fejlen er væk i en ny build.

Bundlinjen

Kodestil er vigtig for at maksimere produktiviteten på et projekt. Smuk kode skrevet i henhold til fælles regler garanterer, at dine kollegaer lettere og hurtigere vil forstå den og ikke vil give dig en øre for kritik. Med moderne udviklingsværktøjer er det ikke så svært at holde sig til stilregler. Jeg håber, at denne anmeldelse har bevist for dig, at dette er sandt. Traditionen tro er her lidt ekstra materiale om emnet:

• Video fra JetBrainsTV: " Inspect Code (IntelliJ IDEA) "
• Anmeldelse af " Code Analysis With Gradle Plugins "
• Kursus " Automatisk kodekvalitet ".