IntelliJ IDEA: Kodestil og kodeformatering

Et programmeringsspråk er veldig likt et talespråk. Den eneste forskjellen er at det er et spesielt språk hvis hovedformål er å lette kommunikasjonen med en datamaskin for å forklare datamaskinen hva vi vil at den skal gjøre. Men du kan ikke ha en personlig samtale med en datamaskin. Da du begynte å lære et programmeringsspråk, så du på bøker eller en pedagogisk ressurs som CodeGym. Og denne ressursen viste deg kode som datamaskinen forstår. Men du bør også forstå det når du lærer om Java-språket. Som med alle språk, har noen formateringskonvensjoner blitt tatt i bruk i programmering. For eksempel, i et høflig samfunn, vil det å skrive SLIK bli ansett som dårlig oppførsel. Og i Java er det å starte en metodes navn med stor bokstav et grovt brudd på kodekonvensjonene. Reglene for Java-kode er gitt i dokumentet Kodekonvensjoner for Java-programmeringsspråket . Kodekonvensjoner kan også regulere mindre detaljer, for eksempel innrykk. Se for deg det fullstendige marerittet som versjonskontroll ville blitt hvis innrykk var inkonsekvent, noen bruker tabulatorer og andre bruker mellomrom. Hvordan ville det vært for noen som trenger å sjekke inn en rettelse på bare én metode, men finner hele filen endret på grunn av forskjeller i mellomrom og tabulatorer? Selvfølgelig, som med vanlig språk, kan konvensjoner endres avhengig av hvor et språk brukes. For eksempel kan du finne Google Java Style Guide og Twitter Java Style Guide i de store vidder av nettet. For denne anmeldelsen trenger vi en testperson. Vi bruker Gradle byggeautomatiseringssystem. Det lar oss komme raskt i gang ved å lage et nytt prosjekt fra en mal. Gradle har en flott plugin: Build Init Plugin . La oss gå til en ny katalog og kjøre følgende kommando der: gradle init --type java-application Start deretter IntelliJ IDEA. Hvis du ser et vindu med et åpent prosjekt (dvs. du ser kodeeditoren og prosjekttreet), lukk dette prosjektet med File -> Close Project. Nå i velkomstvinduet, kjør " Import Project" og importer det nye prosjektet vårt. Når du importerer, setter du av for " Use autoimport". La oss finne ut om vi kan bruke toppmoderne utviklingsverktøy for på en eller annen måte å forenkle livet.

Kodeformatering i IDEA

Etter å ha importert prosjektet, trykk Ctrl+N og gå til klassen AppTest. Dette er standard testklasse. Det ser slik ut:

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

Hva fanger umiddelbart oppmerksomheten din? En merknad på samme linje som en metodeerklæring, som ser stygg ut, ikke sant? Hvordan fikse dette? IntelliJ IDEA har en Codemenyoppføring for forskjellige kodemanipulasjoner. En slik manipulasjon er " Reformat Code", som du kan bruke ved å bruke Ctrl+L. Etter at du har gjort dette, vil merknaden være på én linje, og metodeerklæringen på en annen. Det er verdt å merke seg med en gang at denne operasjonen utføres på den valgte koden . Hvis det ikke er noe valg, utføres formateringsoperasjonen på alt. La oss nå legge til 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, er operasjonen på Stream på én linje. Men hva om vi vil sørge for at de kjedede metodeanropene alltid deles opp i nye linjer hos hver periodeoperatør? Vi kan gjøre dette manuelt. Men husk at vi vil at alt skal skje automatisk. Faktisk vil vi helt sikkert glemme det manuelle trinnet fra tid til annen, og da vil vi ende opp med forskjellig formatering overalt, og det er ikke bra. Så vi må redigere regelen som IDEA bruker for formatering. VelgeFile -> Settingsi IDEA-menyen (eller trykk Ctrl+Alt+S). Skriv inn "Kodestil" i søkefeltet i innstillingsvinduet. I delen "Kodestil" kan du angi innstillinger for flere språk enn bare Java. Men Java er det vi er interessert i akkurat nå. Som du kan se, er innstillingene delt inn i flere faner. En super nyttig funksjon er at et eksempel på operasjonen vises i høyre del av vinduet: Skjermbildet viser at vi kan sette «Chained method calls» til «wrap always», dvs. alltid dele chained method calls i separate linjer. Klikk nå på formateringsknappen igjen i testklassen og vi ser at det virkelig fungerer! Men noen ganger må du formatere litt kode utenfor standard formateringsreglene. Sett opp formateringen som følger: For å forhindre formatering, i "Kodestil"-delen, aktiver formateringsmarkører: Nå kan vi endre testklassen vår slik at koden ikke blir formatert på nytt:

 @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 kanskje lagt merke til at når du trykker Tab, tolker IDEA det som et mellomrom (dette er standardoppførselen). Men du kan endre dette i Code Styledelen " ": Som du kan se, er det mange innstillinger der. Du kan lese mer informasjon om " Code style" innstillinger her: " IDEA Help: Code Style ". Det er en annen viktig formateringsfunksjon: formateringsimporter. Denne operasjonen kjøres separat og kalles " Optimize Imports". Den ligger under Code -> Optimize Imports(Ctrl+Alt+O). Optimalisering av import fjerner unødvendig import og ordner import i riktig rekkefølge i henhold til innstillingene i Importskategorien " Code Style" i innstillingene for Java. Hvis du vil at denne formateringen skal skje automatisk, er det gode nyheter:Lagre handlinger- plugin.

Distribuere innstillinger i en kommando

Vi så ovenfor at du kan tilpasse formateringsstilen din slik du vil. Men hvordan bruker du denne stilen i et team? Veldig lett. Det er flere alternativer. Det enkleste er å lagre et kodestilskjema. Åpne IDEA-innstillinger med File -> Settings(eller trykk Ctrl+Alt+S). I Code Styledelen " " kan vi se "Opplegg". Dette er formateringsskjemaet vårt. Som standard brukes "Standard"-skjemaet og er merket "IDE", noe som betyr at denne innstillingen bare gjelder for vår IDE - den påvirker ikke noen andre. For å lage et "egendefinert" opplegg, bruk knappen til høyre for å lage en kopi og gi den et navn, for eksempel: CodeGym Så kan vi importere eller eksportere innstillingene: Et annet alternativ er å importere IDEA-innstillinger: Et tredje alternativ er Settings Repository. For å bruke Settings Repository, se IntelliJ IDEA Help-dokumentasjonen for flere detaljer på følgende lenke: Settings Repository ". Når vi snakker om å pushe en enhetlig stil på et team, kan jeg heller ikke la være å nevne den gode støtten for stiler fra Eclipse IDE. For å gjøre dette, må du installere en egen plugin: åpne IDEA-innstillinger via Fil -> Innstillinger (Ctrl+Alt+S) og gå til delen "Plugins". For å finne nye plugins, klikk på " "-knappen. Browse RepositoriesDeretter finn Eclipse Code Formatter-pluginen i søkevinduet. Etter at du har installert den, må du starte IDEA på nytt — dette er standardprosedyre. Nå er alt gjort. Det er en ny seksjon i IDEA-innstillingene: "Eclipse Code Formatter".. Det vil se omtrent slik ut:

Skjerpede krav

I tillegg til IDEA-verktøy kan du også bruke plugins for byggeautomatisering for å skjerpe kravene. Du kan ikke manuelt sjekke at noen har brukt riktig formatering. Kanskje du kunne med 5 personer på et lag. Men med 100 personer i et selskap er det ikke realistisk. Og selv fem vil være vanskelig å spore. Og hvorfor kaste bort tiden din på noe av dette? Det vil være mye lettere å hindre at prosjektet bygges dersom reglene brytes. Faktisk er dette et helt eget emne kalt "Inspiser kode". I denne artikkelen vil jeg bare vise deg hvordan det fungerer. En av de mest populære Gradle-plugins (fordi den bygger prosjektet vårt, vil du huske) er pmd. For å aktivere det, bare gå til Gradle-prosjektets byggeskript (build.gradle-filen i roten av prosjektet) og legg til pmd ved siden av resten av pluginene:

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

Nå kan vi legge inn mer detaljerte innstillinger på 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 prosjektet vårt er ødelagt nå. Kjør gradle buildog vi får en feil. Det fine er at det genereres en rapport under byggingen. Og hvis det er feil, får vi en melding 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 noe sånt som dette: Dessuten Problemgir kolonnen " " en lenke til en beskrivelse av problemet på nettsiden til pmd-pluginen. For eksempel, for headerCommentRequirement Requiredfeilen " ", går lenken her: pmd — CommentRequired . Denne feilen er et hint om at klassen vår ikke har et JavaDoc. Vi kan bruke maler for å konfigurere et JavaDoc ovenfor klasser: Og spesifisere innholdet for File Header: Etter det kan vi gjøre kommentaren over App-klassen om til en JavaDoc og se at feilen er borte i en ny konstruksjon.

Bunnlinjen

Kodestil er viktig for å maksimere produktiviteten på et prosjekt. Vakker kode skrevet i henhold til delte regler garanterer at kollegene dine lettere og raskere vil forstå den og ikke gi deg kritikk. Med moderne utviklingsverktøy er det ikke så vanskelig å holde seg til stilregler. Jeg håper denne anmeldelsen har bevist for deg at dette er sant. Tradisjonen tro, her er litt ekstra stoff om emnet:

• Video fra JetBrainsTV: " Inspiser kode (IntelliJ IDEA) "
• Anmeldelse av " Kodeanalyse med Gradle-plugins "
• " Automatiser kodekvalitet " kurs