IntelliJ ÖTLET: Kódolási stílus és kódformázás

A programozási nyelv nagyon hasonlít a beszélt nyelvhez. Az egyetlen különbség az, hogy ez egy speciális nyelv, amelynek fő célja a számítógéppel való kommunikáció megkönnyítése annak érdekében, hogy elmagyarázzuk a számítógépnek, hogy mit akarunk tőle. De számítógéppel nem lehet személyesen beszélgetni. Amikor elkezdett egy programozási nyelvet tanulni, megnézett könyveket vagy valamilyen oktatási forrást, például a CodeGym-et. És ez az erőforrás olyan kódot mutatott meg, amelyet a számítógép megért. De neked is meg kell értened, amikor megtanulod a Java nyelvet. Mint minden nyelv esetében, a programozásban is alkalmaztak bizonyos formázási konvenciókat. Például egy udvarias társadalomban az ILYEN ÍRÁSA rossz modornak számít. Java nyelven pedig egy metódus nevének nagybetűvel kezdése a kódolási konvenciók durva megsértését jelenti. A Java kódra vonatkozó szabályokat a Java programozási nyelv kódegyezményei című dokumentum tartalmazza . A kódolási konvenciók kisebb részleteket is szabályozhatnak, például a behúzást. Képzelje el azt a teljes rémálmot, amelybe a verziószabályozás válna, ha a behúzás következetlen, egyesek tabulátorokat, mások pedig szóközöket használnának. Milyen lenne, ha valakinek egyetlen módszerrel kell benéznie a javítást, de a szóközök és a tabulátorok eltérései miatt az egész fájl megváltozott? Természetesen a hagyományos nyelvekhez hasonlóan a konvenciók változhatnak attól függően, hogy egy nyelvet hol használnak. Például az internet hatalmas kiterjedésében megtalálható a Google Java Style Guide és a Twitter Java Style Guide. Ehhez az áttekintéshez egy tesztalanyra van szükségünk. A Gradle építési automatizálási rendszert fogjuk használni. Ez lehetővé teszi számunkra, hogy gyorsan kezdjük el azáltal, hogy egy sablonból új projektet hozunk létre. A Gradle-nek van egy nagyszerű beépülő modulja: Build Init Plugin . Menjünk egy új könyvtárba, és futtassuk ott a következő parancsot: gradle init --type java-application Ezt követően indítsuk el az IntelliJ IDEA-t. Ha egy nyitott projektet tartalmazó ablakot lát (azaz látja a kódszerkesztőt és a projektfát), zárja be ezt a projektet a segítségével File -> Close Project. Most az üdvözlő ablakban futtassa a " Import Project" parancsot, és importálja az új projektünket. Importáláskor jelölje be a " Use autoimport" jelölőnégyzetet. Gondoljuk át, hogy a legkorszerűbb fejlesztőeszközökkel leegyszerűsíthetjük-e az életet.

Kód formázása az IDEA-ban

A projekt importálása után nyomja meg a Ctrl+N billentyűkombinációt, és lépjen az AppTestosztályba. Ez az alapértelmezett tesztosztály. Ez így néz ki:

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

Mi az, ami azonnal megragadja? Egy megjegyzés ugyanabban a sorban, mint egy metódus deklaráció, ami csúnyán néz ki, igaz? Hogyan lehet ezt kijavítani? Az IntelliJ IDEA " Code" menübejegyzéssel rendelkezik a különböző kódmanipulációkhoz. Az egyik ilyen manipuláció a " Reformat Code", amelyet a Ctrl+L billentyűkombinációval alkalmazhat. Miután ezt megtette, a megjegyzés az egyik sorban, a metódus deklarációja pedig a másikon lesz. Érdemes azonnal megjegyezni, hogy ezt a műveletet az aktuálisan kiválasztott kódon hajtják végre . Ha nincs kijelölés, akkor a formázási művelet mindenen végrehajtódik. Most adjunk hozzá egy új vizsgálati módszert:

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

És két import:

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

Amint látja, a Stream művelete egy sorban történik. De mi van akkor, ha meg akarunk győződni arról, hogy a láncolt metódushívások minden periódusoperátornál mindig új sorokra oszlanak? Ezt manuálisan is megtehetnénk. De ne feledje, hogy azt akarjuk, hogy minden automatikusan történjen. Valóban, a kézi lépést időnként biztosan elfelejtjük, és akkor mindenhol más formázás lesz, és ez nem jó. Tehát módosítanunk kell azt a szabályt, amelyet az IDEA a formázáshoz használ. VálasztFile -> Settingsaz ÖTLET menüben (vagy nyomja meg a Ctrl+Alt+S billentyűkombinációt). Írja be a "Kódstílus" kifejezést a keresőmezőbe a beállítások ablakban. A „Kódstílus” részben a Java nyelven kívül több nyelvhez is megadhat beállításokat. De most a Java érdekel minket. Mint látható, a beállítások több lapra vannak felosztva. Szuper hasznos funkció, hogy az ablak jobb oldalán látható egy példa a műveletre: A képernyőképen látható, hogy a "Chained method calls"-nál beállíthatjuk a "wrap always"-ra, azaz a láncolt metódushívásokat mindig külön sorokra bontjuk. Most kattintson újra a formázás gombra a tesztosztályban, és látjuk, hogy valóban működik! De néha a szabványos formázási szabályokon kívül kell formázni néhány kódot. Állítsa be a formázást az alábbiak szerint: A formázás megelőzése érdekében a "Kódstílus" részben engedélyezze a formázó jelölőket: Most megváltoztathatjuk tesztosztályunkat, hogy a kódja ne formázza újra:

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

Talán észrevette, hogy a Tab megnyomásakor az IDEA szóközként értelmezi (ez az alapértelmezett viselkedés). De ezt megváltoztathatja a " Code Style" részben: Amint látja, nagyon sok beállítás található. További részleteket a " " beállításokról itt olvashat Code style: " IDEA Help: Code Style ". Van egy másik fontos formázási funkció: az importálás formázása. Ez a művelet külön fut, és a neve " Optimize Imports". Code -> Optimize ImportsA (Ctrl+Alt+O) alatt található . Az importálás optimalizálása eltávolítja a szükségtelen importálást, és az importálást a megfelelő sorrendbe rendezi a Java beállítások Imports" " lapján található beállításoknak megfelelően . Code StyleMi több, ha azt szeretné, hogy ez a formázás automatikusan megtörténjen, van egy jó hír:Save Actions plugin.

Beállítások elosztása parancsban

Fentebb láttuk, hogy tetszés szerint testreszabhatja formázási stílusát. De hogyan használja ezt a stílust egy csapaton belül? Nagyon könnyen. Több lehetőség is van. A legegyszerűbb egy kódstílus-séma mentése. Nyissa meg az IDEA beállításait a használatával File -> Settings(vagy nyomja le a Ctrl+Alt+S billentyűkombinációt). A " Code Style" részben láthatjuk a "Sémát". Ez a formázási sémánk. Alapértelmezés szerint az „Alapértelmezett” séma használatos, és az „IDE” címkét viseli, ami azt jelenti, hogy ez a beállítás csak a mi IDE-ünkre vonatkozik – senki másra nincs hatással. Egy "egyedi" séma elkészítéséhez a jobb oldalon található gombbal készítsünk másolatot, és adjunk neki egy nevet, pl.: CodeGym Ezután importálhatjuk vagy exportálhatjuk a beállításokat: Egy másik lehetőség az IDEA beállítások importálása: A harmadik lehetőség a Settings Repository. A Settings Repository használatához tekintse meg az IntelliJ IDEA Súgó dokumentációját további részletekért a következő linken: Settings Repository ". Ha már szóba került az egységes stílus kialakítása a csapaton, nem tudom megemlíteni az Eclipse stílusainak jó támogatását IDE. Ehhez külön beépülő modult kell telepítenie: nyissa meg az IDEA beállításokat a Fájl -> Beállítások menüpontban (Ctrl+Alt+S) és lépjen a "Plugins" részre. Új bővítmények kereséséhez kattintson a " " gombra. Browse RepositoriesEzután Keresse meg az Eclipse Code Formatter bővítményt a keresőablakban. Telepítése után újra kell indítania az IDEA-t – ez a szokásos eljárás. Most már minden készen van. Az IDEA beállításai között van egy új rész: "Eclipse Code Formatter".. Valahogy így fog kinézni:

Szigorúbb követelmények

Az IDEA-eszközökön kívül épít automatizálási bővítményeket is használhat a követelmények szigorítására. Manuálisan nem ellenőrizheti, hogy valaki megfelelő formázást használt-e. Talán 5 emberrel egy csapatban megtehetné. De ha egy cégnél 100 ember dolgozik, ez nem reális. És még ötöt is nehéz lesz követni. És miért vesztegeti az idejét ilyesmire? A szabályok megsértése esetén sokkal könnyebb lenne megakadályozni a projekt megépítését. Valójában ez egy teljesen külön téma, az úgynevezett "Inspect Code". Ebben a cikkben csak azt szeretném bemutatni, hogyan működik. Az egyik legnépszerűbb Gradle bővítmény (mert ez építi fel a projektünket, emlékszel) a pmd. Az engedélyezéséhez lépjen a Gradle projektünk build szkriptjére (a build.gradle fájl a projektünk gyökerében), és adja hozzá a pmd-t a többi beépülő modul mellé:

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

Most ugyanott adhatunk meg részletesebb beállításokat:

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

Most még a projektünk is megszakadt. Futtassa gradle build, és hibát kapunk. A jó dolog az, hogy az összeállítás során jelentés készül. És ha hibák vannak, a következő üzenetet kapjuk:

 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

A jelentésre lépve valami ilyesmit látunk: Sőt, a " Problem" oszlopban található egy hivatkozás a probléma leírására a pmd beépülő modul webhelyén. Például a " headerCommentRequirement Required" hiba esetén a hivatkozás ide kerül: pmd — CommentRequired . Ez a hiba arra utal, hogy osztályunkban nincs JavaDoc. Sablonokkal konfigurálhatunk egy JavaDoc-ot az osztályok felett: És megadhatjuk a tartalmát a File Header: Ezt követően az App osztály feletti megjegyzést JavaDoc-ká alakíthatjuk, és megnézhetjük, hogy a hiba eltűnt egy új buildben.

Alsó vonal

A kódstílus fontos a projekt termelékenységének maximalizálásához. A megosztott szabályok szerint megírt gyönyörű kód garantálja, hogy munkatársai könnyebben és gyorsabban megértsék, és ne kapjon füles kritikát. A modern fejlesztőeszközökkel nem olyan nehéz betartani a stílusszabályokat. Remélem, ez az áttekintés bebizonyította, hogy ez igaz. A hagyományokat követve álljon itt egy kis extra anyag a témában:

• Videó a JetBrainsTV-től: " Inspect Code (IntelliJ IDEA) "
• „ Kódelemzés Gradle beépülő modulokkal ” áttekintése
• " Kódminőség automatizálása " tanfolyam