IntelliJ IDEA: codeerstijl en codeopmaak

Een programmeertaal lijkt erg op een gesproken taal. Het enige verschil is dat het een speciale taal is waarvan het belangrijkste doel is om de communicatie met een computer te vergemakkelijken om de computer uit te leggen wat we willen dat het doet. Maar met een computer kun je geen persoonlijk gesprek voeren. Toen je een programmeertaal begon te leren, keek je naar boeken of een educatief hulpmiddel zoals CodeGym. En deze bron liet je code zien die de computer begrijpt. Maar ook u zou het moeten begrijpen terwijl u de Java-taal leert kennen. Zoals bij elke taal, zijn er bij het programmeren enkele opmaakconventies overgenomen. In een beleefde samenleving zou schrijven als dit bijvoorbeeld als slechte manieren worden beschouwd. En in Java is het starten van de naam van een methode met een hoofdletter een grove schending van codeerconventies. De regels voor Java-code worden gegeven in het document Codeconventies voor de Java-programmeertaal . Codeerconventies kunnen ook kleinere details regelen, zoals inspringen. Stel je de totale nachtmerrie voor die versiebeheer zou worden als de inspringing niet consistent was, sommige mensen tabs gebruikten en andere mensen spaties gebruikten. Hoe zou het zijn voor iemand die een fix op slechts één manier moet inchecken, maar merkt dat het hele bestand is gewijzigd vanwege verschillen in spaties en tabbladen? Natuurlijk kunnen conventies, net als bij gewone taal, veranderen afhankelijk van waar een taal wordt gebruikt. Op het uitgestrekte web vindt u bijvoorbeeld de Google Java Style Guide en de Twitter Java Style Guide. Voor deze review hebben we een proefpersoon nodig. We zullen het Gradle build-automatiseringssysteem gebruiken. Hiermee kunnen we snel aan de slag door een nieuw project te maken op basis van een sjabloon. Gradle heeft een geweldige plug-in: Build Init Plugin . Laten we naar een nieuwe map gaan en daar de volgende opdracht uitvoeren: gradle init --type java-application Start daarna IntelliJ IDEA. Als u een venster ziet met een open project (dwz u ziet de code-editor en projectboom), sluit dit project dan af met File -> Close Project. Voer nu in het welkomstvenster " Import Project" uit en importeer ons nieuwe project. Schakel bij het importeren het Use autoimportselectievakje " " in. Laten we eens kijken of we state-of-the-art ontwikkeltools kunnen gebruiken om het leven op de een of andere manier te vereenvoudigen.

Codeopmaak in IDEA

Druk na het importeren van het project op Ctrl+N en ga naar de AppTestklas. Dit is de standaard testklasse. Het ziet er zo uit:

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

Wat springt meteen in het oog? Een annotatie op dezelfde regel als een methodedeclaratie, die er lelijk uitziet, toch? Hoe dit op te lossen? IntelliJ IDEA heeft een Codemenu-item " " voor verschillende codemanipulaties. Een dergelijke manipulatie is " Reformat Code", die u kunt toepassen met Ctrl+L. Nadat u dit hebt gedaan, staat de annotatie op de ene regel en de methodedeclaratie op een andere. Het is de moeite waard om meteen op te merken dat deze bewerking wordt uitgevoerd op de momenteel geselecteerde code . Als er geen selectie is, wordt de formatteringsbewerking op alles uitgevoerd. Laten we nu een nieuwe testmethode toevoegen:

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

En twee invoer:

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

Zoals je kunt zien, staat de bediening op de Stream op één regel. Maar wat als we er zeker van willen zijn dat de geketende methode-aanroepen altijd worden opgesplitst in nieuwe regels bij elke periode-operator? We zouden dit handmatig kunnen doen. Maar vergeet niet dat we willen dat alles automatisch gebeurt. Inderdaad, we zullen de handmatige stap van tijd tot tijd zeker vergeten, en dan zullen we overal een andere opmaak krijgen, en dat is niet goed. We moeten dus de regel bewerken die IDEA gebruikt voor opmaak. KiezenFile -> Settingsin het IDEA-menu (of druk op Ctrl+Alt+S). Typ "Codestijl" in het zoekveld in het instellingenvenster. In het gedeelte "Codestijl" kunt u instellingen opgeven voor meer talen dan alleen Java. Maar Java is waar we nu in geïnteresseerd zijn. Zoals u kunt zien, zijn de instellingen onderverdeeld in verschillende tabbladen. Een superhandige functie is dat een voorbeeld van de bewerking wordt getoond in het rechterdeel van het venster: De schermafbeelding laat zien dat we "Chained method calls" kunnen instellen op "altijd inpakken", dwz altijd splitsen chained method calls in afzonderlijke regels. Klik nu weer op de opmaakknop in de testklas en we zien dat het echt werkt! Maar soms moet u code opmaken buiten de standaard opmaakregels. Stel de opmaak als volgt in: Om formattering te voorkomen, schakelt u in het gedeelte "Codestijl" formattermarkeringen in: Nu kunnen we onze testklasse wijzigen zodat de code niet opnieuw wordt geformatteerd:

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

Het is je misschien opgevallen dat wanneer je op Tab drukt, IDEA dit interpreteert als een spatie (dit is het standaardgedrag). Maar u kunt dit wijzigen in de Code Stylesectie " ": Zoals u kunt zien, zijn daar veel instellingen. Meer details over " Code style" instellingen kunt u hier lezen: " IDEA Help: Code Style ". Er is nog een belangrijke opmaakfunctie: het formatteren van geïmporteerde bestanden. Deze operatie wordt apart uitgevoerd en heet " Optimize Imports". Het bevindt zich onder Code -> Optimize Imports(Ctrl+Alt+O). Het optimaliseren van import verwijdert onnodige import en rangschikt import in de juiste volgorde volgens de instellingen in het " Imports" tabblad van de " Code Style" instellingen voor Java. Bovendien, als u wilt dat deze opmaak automatisch gebeurt, is er goed nieuws:Save Actions- plug-in.

Instellingen distribueren in een opdracht

We zagen hierboven dat u uw opmaakstijl kunt aanpassen zoals u wilt. Maar hoe gebruik je deze stijl binnen een team? Heel makkelijk. Er zijn verschillende opties. Het eenvoudigste is om een ​​codestijlschema op te slaan. Open IDEA-instellingen met File -> Settings(of druk op Ctrl+Alt+S). In de Code Stylesectie " " kunnen we "Schema" zien. Dit is ons opmaakschema. Standaard wordt het "Default"-schema gebruikt en heeft het label "IDE", wat betekent dat deze instelling alleen van toepassing is op onze IDE - het heeft geen invloed op iemand anders. Om een ​​"aangepast" schema te maken, gebruikt u de knop rechts om een ​​kopie te maken en deze een naam te geven, bijvoorbeeld: CodeGym Vervolgens kunnen we de instellingen importeren of exporteren: Een andere optie is om IDEA-instellingen te importeren: Een derde optie is de Settings Repository. Als u de instellingenopslagplaats wilt gebruiken, raadpleegt u de IntelliJ IDEA Help-documentatie voor meer informatie via de volgende link: Instellingenopslagplaats ". Over het pushen van een uniforme stijl in een team gesproken, ik kan ook niet anders dan de goede ondersteuning voor stijlen van de Eclipse noemen IDE. Hiervoor moet u een aparte plug-in installeren: open IDEA-instellingen via Bestand -> Instellingen (Ctrl+Alt+S) en ga naar het gedeelte "Plug-ins". Om nieuwe plug-ins te vinden, klikt u op de knop " " Browse Repositories. zoek de Eclipse Code Formatter-plug-in in het zoekvenster. Na installatie moet u IDEA opnieuw opstarten - dit is de standaardprocedure. Nu is alles klaar. Er is een nieuwe sectie in de IDEA-instellingen: "Eclipse Code Formatter".. Het zal er ongeveer zo uitzien:

Strengere eisen

Naast IDEA-tools kunt u ook build-automatiseringsplug-ins gebruiken om vereisten aan te scherpen. U kunt op geen enkele manier handmatig controleren of iemand de juiste opmaak heeft gebruikt. Misschien lukt het wel met 5 man in een team. Maar met 100 man in een bedrijf is dat niet realistisch. En zelfs vijf zullen moeilijk te volgen zijn. En waarom zou je hier je tijd aan verspillen? Het zou veel gemakkelijker zijn om te voorkomen dat het project wordt gebouwd als de regels worden overtreden. In feite is dit een heel apart onderwerp genaamd "Inspect Code". In dit artikel wil ik je laten zien hoe het werkt. Een van de meest populaire Gradle-plug-ins (omdat het ons project bouwt, zul je je herinneren) is pmd. Om het in te schakelen, ga je gewoon naar het build-script van ons Gradle-project (het build.gradle-bestand in de root van ons project) en voeg je pmd toe naast de rest van de plug-ins:

 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 kunnen we op dezelfde plaats meer gedetailleerde instellingen invoeren:

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

Zelfs ons project is nu kapot. Ren gradle builden we krijgen een foutmelding. Het leuke is dat er tijdens het bouwen een rapport wordt gegenereerd. En als er fouten zijn, krijgen we een bericht als dit:

 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

Als we naar het rapport gaan, zien we zoiets als dit: Bovendien Problemgeeft de kolom " " een link naar een beschrijving van het probleem op de website van de pmd-plug-in. Voor de headerCommentRequirement Requiredfout " " gaat de link bijvoorbeeld hier: pmd — CommentRequired . Deze fout is een hint dat onze klas geen JavaDoc heeft. We kunnen sjablonen gebruiken om een ​​JavaDoc boven klassen te configureren: En specificeer de inhoud voor de File Header: Daarna kunnen we de opmerking boven de App-klasse omzetten in een JavaDoc en zien dat de fout is verdwenen in een nieuwe build.

het komt neer op

Codestijl is belangrijk om de productiviteit van een project te maximaliseren. Mooie code geschreven volgens gedeelde regels garandeert dat je collega's het gemakkelijker en sneller begrijpen en je geen oor vol kritiek bezorgt. Met moderne ontwikkeltools is het niet zo moeilijk om je aan stijlregels te houden. Ik hoop dat deze recensie u heeft bewezen dat dit waar is. Traditiegetrouw volgt hier wat extra materiaal over het onderwerp:

• Video van JetBrainsTV: " Code inspecteren (IntelliJ IDEA) "
• Herziening van " Code-analyse met Gradle-plug-ins "
• Cursus " Codekwaliteit automatiseren ".