IntelliJ IDEA: Code Style at Formatting

Pinapadali ng mga modernong kasangkapan ang proseso ng pag-unlad. Sa partikular, mas madaling subaybayan ang istilo ng iyong code, sinusubukang bawasan ang "hindi awtorisadong" pag-format nito. Sa pagsusuring ito, ipinapanukala kong pamilyar ka sa kung anong mga tool ang ibinibigay ng IntelliJ Idea IDE sa developer upang gawing kaaya-aya basahin at madaling maunawaan ang code.

Panimula

Ang isang programming language ay halos kapareho sa wikang sinasalita ng mga tao. Ang pagkakaiba lang ay ito ay isang espesyal na wika na unang ginagamit upang makipag-usap sa isang computer upang ipaliwanag dito kung ano ang gusto natin mula dito. Ngunit maaaring walang one-on-one na komunikasyon sa isang computer. Kahit noong nagsimula kang mag-aral ng programming language, tumingin ka sa isang libro o ilang mapagkukunang pang-edukasyon tulad ng JavaRush. At sa source na ito nakita mo ang code na mauunawaan ng isang computer. Ngunit dapat mo ring maunawaan ito habang nakakuha ka ng kaalaman sa wikang Java. Tulad ng sa anumang wika, ang programming ay may ilang mga patakaran para sa pagbuo ng code. Halimbawa, ang pagsulat na may bakod sa magalang na lipunan ay itinuturing na masamang asal, at sa Java ang pagtawag sa isang paraan na may malaking titik ay isang matinding paglabag sa istilo ng code. Ang mga patakaran para sa pag-format ng Java code ay binuo sa dokumento ng Java Code Convention . Bilang karagdagan, ang istilo ng code ay maaaring mag-regulate ng mas maliliit na detalye, tulad ng indentation. At kapag ginamit ang mga tool sa pagkontrol ng bersyon, isipin ang buong bangungot kapag nag-save ang lahat ng file na naka-indent bilang tab o naka-indent bilang isang space. Ano ang magiging hitsura ng isang tao na kailangang suriin ang pag-edit sa isang paraan lamang, ngunit ang buong file ay mababago dahil sa pagwawasto ng mga puwang sa mga tab o kabaliktaran. Naturally, tulad ng ordinaryong wika, ang istilo ay maaaring mag-iba depende sa kung saan ito ginagamit. Halimbawa, sa Internet makikita mo ang Google Java Style Guide o Twitter Java Style Guide . Para sa artikulong ito sa pagsusuri, kakailanganin namin ang isang paksa ng pagsubok. Gamitin natin ang serbisyo ng Gradle project build system. Ito ay magpapahintulot sa amin na lumikha ng isang bagong proyekto gamit ang isang template para sa isang mabilis na pagsisimula. May magandang plugin ang Gradle: Build Init Plugin . Pumunta tayo sa bagong direktoryo at isagawa ang utos doon: gradle init --type java-application Pagkatapos nito, ilunsad ang IntelliJ Idea. Kung makakita ka ng isang window na may bukas nang proyekto (makikita mo ang editor ng code, ang puno ng istraktura ng proyekto), isara ang proyektong ito gamit ang File -< Close Project. Ngayon sa welcome window, isasagawa "Import Project"at ii-import namin ang aming bagong proyekto. Kapag nag-import, itakda ang bandila "Use autoimport". Alamin natin kung posible bang gawing simple ang buhay sa tulong ng mga modernong tool sa pag-unlad.

Pag-format ng Code sa Ideya

Pagkatapos i-import ang proyekto, pindutin ang kumbinasyon ng key Ctrl+Nat pumunta sa klase AppTest. Ang klase na ito ay ang default na klase ng pagsubok. Mukhang ganito:

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

Ano agad ang pumukaw sa iyong mata dito? Sumasang-ayon ang isang anotasyon na may deklarasyon ng pamamaraan sa isang linya, na mukhang pangit. Paano ito ayusin? Ang IntelliJ Idea ay may seksyon ng menu "Code"para sa iba't ibang manipulasyon ng code. Ang isa sa gayong mga manipulasyon ay "Reformat Code"isang pangunahing kumbinasyon Ctrl + L. Pagkatapos ng aplikasyon, ang anotasyon ay nasa isang linya, at ang pamamaraan mismo ay nasa isa pa. Ito ay nagkakahalaga kaagad na tandaan na ang operasyong ito ay isinasagawa sa isang napiling seksyon ng code . At kung walang ganoong bagay, ang operasyon ng pag-format ay isasagawa sa lahat ng nilalaman. Magdagdag tayo ngayon ng bagong paraan ng pagsubok:

@Test
public void testSummOfOddNumbers() {
	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));
}

At dalawang import:

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

Tulad ng nakikita mo, ang operasyon sa Stream ay inilalagay sa isang linya. Ngunit paano kung gusto nating tiyakin na ang mga pamamaraan na ang mga tawag ay nakakadena ay palaging nahahati sa mga punto sa mga bagong linya? Sa isang banda, magagawa natin ito nang manu-mano. Ngunit tandaan na gusto nating lahat ay gumana para sa atin. Pagkatapos ng lahat, paminsan-minsan ay makakalimutan natin, at ang format ng code ay magiging iba sa lahat ng dako, at ito ay hindi maganda. Lumalabas na kailangan mong i-edit ang panuntunan kung saan nagsasagawa ng pag-format ang Idea. Piliin ang item na Ideya sa menu File -> Settings(o i-click ang Ctrl + Alt + S). Sa field ng paghahanap sa window ng mga setting, isulat ang "Estilo ng code". Sa seksyon ng Code style posible na tukuyin ang mga setting hindi lamang para sa Java. Ngunit ngayon kami ay interesado sa Java. Tulad ng nakikita mo, ang mga setting ay nahahati sa ilang mga tab. Ang pinakakapaki-pakinabang ay ang resulta ng pagbabago ay ipapakita sa isang halimbawa sa kanang bahagi ng window: Gaya ng nakikita mo sa screenshot, maaari naming tukuyin ang setting para sa "Mga tawag na naka-chain na paraan" bilang "i-wrap palagi", i.e. palaging hatiin para sa mga merged method na tawag. Ngayon, pindutin natin muli ang pag-format sa pagsubok at tingnan kung talagang gumagana ito! Ngunit minsan nangyayari na kailangang mag-format ng ilang code sa labas ng pangkalahatang mga panuntunan sa pag-format. I-set up natin ang pag-format tulad ng sumusunod: Upang paganahin ang pag-format na hindi paganahin, ang suporta para sa hindi paganahin ang mga marker sa pag-format ay dapat paganahin sa seksyon ng Code Style: Ngayon ay maaari naming baguhin ang code ng aming pagsubok upang ang pag-format nito ay mananatili sa anyo kung saan namin ito isinusulat:

@Test
public void testSummOfOddNumbers() {
	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
}

Oo, kung mapapansin mo: kapag pinindot mo ang Tab, binibigyang-kahulugan ito ng Idea bilang mga puwang para sa iyo (default na gawi). Ngunit maaari mong baguhin ito doon sa Code Style: Tulad ng nakikita mo, mayroong isang malaking iba't ibang mga setting. Maaari kang magbasa ng higit pa tungkol sa mga setting ng Code style dito: " Idea Help: Code Style ". May isa pang mahalagang tampok sa pag-format - pag-import ng pag-format. Ito ay isinagawa nang hiwalay at tinatawag "Optimize Imports"at matatagpuan sa item ng menu Code -> Optimize Imports(Ctrl + Alt + O). Inaalis ng pag-optimize ng import ang mga hindi kinakailangang pag-import at inilalagay din ang mga ito sa tamang pagkakasunud-sunod ayon sa mga setting sa tab na Mga Import ng Code Style para sa mga setting ng Java. Gayundin, kung gusto mong awtomatikong mangyari ang pag-format, ang magandang balita ay magagawa mo ito gamit ang plugin na Save Actions .

Pamamahagi ng Mga Setting sa isang Koponan

Mahusay, nakita namin sa itaas na maaari naming i-customize ang istilo ng pag-format upang umangkop sa amin. Ngunit paano magagamit ang istilong ito sa isang koponan? Napakasimple. Mayroong ilang mga pagpipilian. Ang pinakamadali ay i-save ang diagram. Buksan ang mga setting ng Ideya sa pamamagitan ng File -> Settings (o pindutin ang Ctrl + Alt + S). Sa seksyong Estilo ng Code makikita natin ang Scheme ng inskripsyon. Ito ang aming formatting scheme. Bilang default, ang isang scheme ay tinukoy na may pangalan na Default at sa tabi nito ay ang anotasyon na IDE: nangangahulugan ito na ang setting na ito ay para lamang sa aming IDE, at hindi ito nakakaapekto sa sinuman. Para gumawa ng "custom" na scheme, i-click ang button sa kanan para gumawa ng "duplicate" at bigyan ito ng pangalan, halimbawa: JavaRush Pagkatapos nito, magagawa naming i-import o i-export ang mga setting: Ang isa pang pagpipilian ay ang pag-import ng mga setting ng Ideya sa pag-import: Ang ikatlong opsyon ay Settings Repository. Para sa higit pang impormasyon sa paggamit ng Settings Repository, tingnan ang dokumentasyong "IntelliJ Idea Help: Settings Repository ". Sa paksa ng pamamahagi ng isang istilo sa koponan, hindi ko rin maiwasang tandaan ang magandang suporta para sa mga istilo mula sa Eclipse IDE. Upang gawin ito, kakailanganin mong mag-install ng isang hiwalay na plugin: buksan ang mga setting ng Ideya sa pamamagitan ng File -> Mga Setting (Ctrl + Alt + S) at pumunta sa seksyong Mga Plugin. Upang maghanap ng mga bagong plugin, i-click ang button "Browse Repositories", pagkatapos nito ay makikita natin ang Eclipse Code Formatter plugin sa window ng paghahanap. Ngayon, pagkatapos ng pag-install, kailangan mong i-restart ang Ideya - ito ay isang karaniwang pamamaraan. Pagkatapos nito, sa parehong lugar, sa mga setting ng Ideya, makakahanap tayo ng bagong seksyon: "Formatter ng Code ng Eclipse". Matatagpuan dito ang isang halimbawa ng format na file para sa Eclipse . Magiging ganito ang hitsura nito:

Mga kinakailangan sa paghihigpit

Bilang karagdagan sa mga tool ng Idea, maaari mo ring gamitin ang mga plugin ng build system upang higpitan ang mga kinakailangan. Walang paraan upang suriin na ang isang tao ay gumamit ng pag-format. Kung mayroong 5 tao sa koponan, posible pa rin ito. Kung ang kumpanya ay may 100 tao, ito ay hindi makatotohanan. Oo, kahit lima ay mahirap subaybayan. At bakit mag-aaksaya ng oras dito? Mas madaling ipagbawal ang pagkolekta ng isang proyekto kung ang ilang mga patakaran ay nilabag. Sa katunayan, ito ay isang buong hiwalay na paksa na tinatawag na "Inspect Code". Para sa mga layunin ng artikulong ito, gusto ko lang ipakita kung paano ito gumagana. Ang isa sa mga pinakakaraniwang plugin para sa Gradle (dahil kinokolekta nito ang aming proyekto, kung naaalala mo) ay pmd . Upang paganahin ito, pumunta lamang sa build script ng aming gradle project (ang build.gradle file sa ugat ng aming proyekto) at tukuyin ang pmd dito sa tabi ng iba pang mga plugin:

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

Ngayon ay maaari na tayong magtakda ng mas detalyadong mga setting doon:

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

Kahit sa project namin, hindi na maganda ang lahat. Patakbuhin natin ang gradle build at magkaroon ng error. Ang maganda ay ang isang ulat ay nabuo sa panahon ng pagpupulong. At kung may mga error, makakatanggap kami ng mensahe tulad ng:

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

Kung pupunta tayo sa ulat, makikita natin ang tulad ng: Bukod dito, sa column na Problema ay mayroong isang link sa isang paglalarawan ng problema sa website ng pmd plugin. Halimbawa, para sa error na "headerCommentRequirement Requirement" napupunta ang link dito: pmd - CommentRequired . Ang error na ito ay nagpapahiwatig sa amin na ang aming klase ay walang JavaDoc. Ang pagkakaroon ng JavaDoc sa mga klase ay maaaring i-configure gamit ang mga template: At tukuyin ang mga nilalaman para sa File Header: Pagkatapos nito, maaari nating gawing JavaDoc ang komento sa itaas ng klase ng App at makita gamit ang isang bagong Build na nawala ang error.

Bottom line

Ang istilo ng code ay mahalaga para sa isang produktibong proyekto. Ang magandang code na nakasulat ayon sa mga pangkalahatang tuntunin ay ang garantiya na mas madali at mabilis na mauunawaan ito ng iyong mga kasamahan, at hindi magsasabi ng ilang magiliw na bagay tungkol sa iyo. Dahil sa modernong mga tool sa pag-unlad, ang pagsunod sa mga patakaran ay hindi napakahirap. Umaasa ako na ang pagsusuri na ito ay nagpakita na ito nga ang kaso. Well, gaya ng dati, isang maliit na materyal sa paksa:

• Video mula sa JetBrainsTV: " Inspect Code (IntelliJ IDEA) "
• Pagsusuri ng " Pagsusuri ng Code Gamit ang Gradle Plugin "
• Kurso na " I-automate ang Kalidad ng Code "

#Viacheslav