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:
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:
Amint látja, nagyon sok beállítás található. További részleteket a " " beállításokról itt olvashat
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.
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:
Sőt, a "
És megadhatjuk a tartalmát a
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.

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 azAppTest
osztá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 -> Settings
az Ö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: 


@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: 
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 Imports
A (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 Style
Mi 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ávalFile -> 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 


Browse Repositories
Ezután Keresse meg az Eclipse Code Formatter bővítményt a keresőablakban. 

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: 
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: 
File Header
: 
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
GO TO FULL VERSION