Čisté kódovanie v Jave

1. Prehľad

V tomto tutoriáli si prejdeme princípy čistého kódovania. Pochopíme tiež, prečo je čistý kód dôležitý a ako to dosiahnuť v Jave. Ďalej uvidíme, či sú k dispozícii nejaké nástroje, ktoré by nám pomohli.

2. Čo je Čistý kódex?

Než teda prejdeme k podrobnostiam čistého kódu, poďme pochopiť, čo myslíme pod čistým kódom. Úprimne, na túto otázku nemôže byť jedna dobrá odpoveď. V programovaní sa niektoré obavy dotýkajú všetkých, a preto vedú k všeobecným zásadám. Potom však každý programovací jazyk a paradigma predstavuje svoju vlastnú sadu nuáns, ktorá nás zaväzuje prijať vhodné postupy.

Široko, čistý kód možno zhrnúť ako kód, ktorý môže každý vývojár ľahko prečítať a zmeniť. Aj keď to môže znieť ako zjednodušenie konceptu, uvidíme ďalej v tutoriále, ako sa to vybuduje. Kdekoľvek sa dozvieme o čistom kóde, možno narazíme na nejaký odkaz na Martina Fowlera. Takto popisuje čistý kód na jednom z miest:

Každý blázon môže napísať kód, ktorému počítač porozumie. Dobrí programátori píšu kód, ktorému ľudia rozumejú.

3. Prečo by nám malo záležať na čistom kódexe?

Písanie čistého kódexu je otázkou osobného zvyku, rovnako ako otázkou zručnosti. Ako vývojár časom rastieme prostredníctvom skúseností a znalostí. Musíme sa však spýtať, prečo by sme mali investovať do vývoja čistého kódu? Zistili sme, že pre ostatných bude pravdepodobne jednoduchšie čítať náš kód, ale je to dostatočne motivačné? Poďme zistiť!

Princípy čistého kódovania nám pomáhajú dosiahnuť veľa želaných cieľov týkajúcich sa softvéru, ktorý plánujeme vyrobiť. Prejdime si ich, aby sme tomu lepšie porozumeli:

  • Udržiavateľný program Codebase: Akýkoľvek softvér, ktorý vyvíjame, má produktívny život a počas tohto obdobia bude vyžadovať zmeny a všeobecnú údržbu. Čistý kód môže pomôcť vyvinúť softvér, ktorý sa dá ľahko meniť a udržiavať v priebehu času.
  • Ľahšie riešenie problémov: Softvér môže vykazovať neúmyselné správanie v dôsledku rôznych vnútorných alebo vonkajších faktorov. Môže to často vyžadovať rýchly obrat, pokiaľ ide o opravy a dostupnosť. Softvér vyvinutý na princípoch čistého kódovania je ľahšie vyriešiť problémy.
  • Rýchlejšie pripojenie: Počas svojej životnosti uvidí softvér mnoho vývojárov, ktorí ich vytvárajú, aktualizujú a udržiavajú. Vývojári sa k nim pripoja v rôznych časových okamihoch. Toto si vyžaduje rýchlejšie pripojenie, aby ste udržali vysokú produktivitua čistý kód pomáha dosiahnuť tento cieľ.

4. Charakteristika čistého kódexu

Kódové základne napísané pomocou princípov čistého kódovania vykazujú niekoľko charakteristík, ktoré ich odlišujú. Prejdime si niektoré z týchto charakteristík:

  • Zaostrené: Kus kód by mal byť napísaný na vyriešenie konkrétneho problému. Nemalo by robiť nič striktne, čo nesúvisí s riešením daného problému. To platí pre všetky úrovne abstrakcie v kódovej základni, ako sú metóda, trieda, balík alebo modul.
  • Jednoduché: Toto je zďaleka najdôležitejšia a často ignorovaná vlastnosť čistého kódu. Softvér návrh a implementácia musia byť čo najjednoduchšie, ktoré nám môžu pomôcť dosiahnuť požadované výsledky. Zvyšujúca sa zložitosť kódovej základne ich robí náchylnými na chyby a ťažko sa čítajú a udržiavajú.
  • Testovateľné: Čistý kód, aj keď je jednoduchý, musí vyriešiť daný problém. Musí to byť intuitívne a ľahké otestovať databázu kódov, najlepšie automatizovaným spôsobom. Toto pomáha určiť základné správanie sa kódovej základne a uľahčuje jej zmenu bez toho, aby sa niečo porušilo.

To nám pomáha dosiahnuť ciele, o ktorých sa hovorí v predchádzajúcej časti. Je užitočné začať s vývojom týchto vlastností v mysli v porovnaní s refaktorom neskôr. To vedie k nižším celkovým nákladom na vlastníctvo životného cyklu softvéru.

5. Vyčistite kódovanie v Jave

Teraz, keď sme prešli dostatočným pozadím, sa pozrime, ako môžeme do Java začleniť princípy čistého kódovania. Java ponúka veľa osvedčených postupov, ktoré nám môžu pomôcť pri písaní čistého kódu. Zaradíme ich do rôznych segmentov a pochopíme, ako napísať čistý kód so vzorkami kódu.

5.1. Štruktúra projektu

Aj keď Java nepresadzuje žiadnu štruktúru projektu, je vždy užitočné postupovať podľa konzistentného vzoru na usporiadanie našich zdrojových súborov, testov, konfigurácií, údajov a ďalších artefaktov kódu. Maven, populárny nástroj na vytváranie pre Javu, predpisuje konkrétnu štruktúru projektu. Aj keď Maven nemusíme používať, vždy je pekné držať sa konvencií.

Pozrime sa na niektoré priečinky, ktoré Maven navrhuje vytvoriť:

  • src / main / java: Pre zdrojové súbory
  • src / main / resources: Pre súbory zdrojov, napríklad vlastnosti
  • src / test / java: Pre testovacie zdrojové súbory
  • src / test / zdroje: Pre testovacie súbory zdrojov, napríklad vlastnosti

Podobné sú aj ďalšie populárne projektové štruktúry, napríklad Bazel navrhnuté pre Javu, a mali by sme si ich zvoliť v závislosti od našich potrieb a publika.

5.2. Konvencia o pomenovaní

Nasledujúci konvencie pomenovania môžu viesť k tomu, aby bol náš kód čitateľný a teda udržiavateľný. Rod Johnson, tvorca jari, zdôrazňuje význam pomenovacích konvencií na jar:

"... ak vieš, čo niečo robí, máš dosť dobrú šancu uhádnuť názov jarnej triedy alebo jej rozhranie ..."

Java predpisuje súbor pravidiel, ktoré treba dodržiavať, pokiaľ ide o pomenovanie ľubovoľného výrazu v jazyku Java. Dobre tvarovaný názov pomáha nielen pri čítaní kódu, ale tiež veľa informuje o zámere kódu. Zoberme si niekoľko príkladov:

  • Triedy: Trieda, pokiaľ ide o objektovo orientované koncepty, je návrhom objektov, ktoré často predstavujú objekty v reálnom svete. Preto je zmysluplné používať podstatné mená na pomenovanie tried, ktoré ich dostatočne popisujú:
zákazník verejnej triedy {}
  • Premenné: Premenné v Jave zachytávajú stav objektu vytvoreného z triedy. Názov premennej by mal jasne popisovať zámer premennej:
public class Customer {private String customerName; }
  • Metódy: Metódy v Jave sú vždy súčasťou tried, a preto vo všeobecnosti predstavujú akciu týkajúce sa stavu objektu vytvoreného z triedy. Preto je užitočné pomenovať metódy pomocou slovies:
public class Customer {private String customerName; public String getCustomerName () {return this.customerName; }}

Aj keď sme diskutovali iba o tom, ako pomenovať identifikátor v Jave, upozorňujeme, že existujú ďalšie osvedčené postupy, ako napríklad ťavie puzdro, ktoré by sme mali dodržiavať kvôli čitateľnosti. Môže existovať viac konvencií týkajúcich sa pomenovania rozhraní, enumov, konštánt.

5.3. Štruktúra zdrojového súboru

Zdrojový súbor môže obsahovať rôzne prvky. Zatiaľ čo Java prekladač vynucuje určitú štruktúru, veľká časť je plynulá. Dodržiavanie konkrétneho poradia umiestňovania prvkov do zdrojového súboru však môže výrazne zlepšiť čitateľnosť kódu. Existuje niekoľko populárnych sprievodcov štýlmi, z ktorých sa môžete inšpirovať, napríklad jeden od spoločnosti Google a druhý od jari.

Pozrime sa, ako by malo vyzerať typické usporiadanie prvkov v zdrojovom súbore:

  • Vyhlásenie o balíku
  • Import výpisov
    • Všetky statické importy
    • Všetky nestatické dovozy
  • Presne jedna trieda najvyššej úrovne
    • Premenné triedy
    • Premenné inštancie
    • Konštruktéri
    • Metódy

Okrem vyššie uvedeného metódy je možné zoskupiť na základe ich funkčnosti alebo rozsahu. Neexistuje jeden dobrý dohovor a táto myšlienka by mala byť rozhodol raz a potom dôsledne nasledoval.

Pozrime sa na dobre zostavený zdrojový súbor:

# /src/main/java/com/baeldung/application/entity/Customer.java balíček com.baeldung.application.entity; import java.util.Date; public class Customer {private String customerName; súkromné ​​Dátum spojeniaDátum; verejný zákazník (reťazec customerName) {this.customerName = customerName; this.joiningDate = nový dátum (); } public String getCustomerName () {return this.customerName; } public Date getJoiningDate () {return this.joiningDate; }}

5.4. Biele medzery

Všetci vieme, že v porovnaní s veľkým blokom textu je ľahšie prečítať a porozumieť krátkym odsekom. Nie je to veľmi odlišné, pokiaľ ide aj o čítanie kódu. Dobre umiestnené a konzistentné medzery a prázdne riadky môžu zvýšiť čitateľnosť kódu.

Myšlienkou je zaviesť do kódu logické zoskupenia, ktoré by mohli pomôcť usporiadať myšlienkové procesy pri pokuse o ich prečítanie. Neexistuje jediné pravidlo, ktoré by sa tu malo prijať, iba všeobecný súbor usmernení a inherentný úmysel udržať čitateľnosť v centre pozornosti:

  • Dva prázdne riadky pred spustením statických blokov, polí, konštruktorov a vnútorných tried
  • Jeden prázdny riadok za podpisom metódy, ktorý je viacriadkový
  • Jediný priestor oddeľujúci vyhradené kľúčové slová, ako keby, pre, úlovok od otvorenej zátvorky
  • Jediný priestor oddeľujúci vyhradené kľúčové slová, podobne ako iné slová, úlovok od záverečnej zátvorky

Tento zoznam nie je vyčerpávajúci, ale mal by nám slúžiť ako pomôcka.

5.5. Odsadenie

Aj keď je to dosť triviálne, takmer každý vývojár by sa zaručil za to dobre odsadený kód je oveľa ľahšie čitateľný a ľahšie pochopiteľný. V jazyku Java neexistuje jediná konvencia pre odsadenie kódu. Kľúčom je tu buď prijať populárny dohovor, alebo definovať súkromný dohovor a potom ho dôsledne dodržiavať v celej organizácii.

Pozrime sa na niektoré dôležité kritériá odsadenia:

  • Typickým osvedčeným postupom je použiť štyri medzery, jednotku odsadenia. Upozorňujeme, že niektoré pokyny navrhujú namiesto medzier kartu. Aj keď tu neexistuje absolútna najlepšia prax, kľúčom zostáva konzistencia!
  • Za normálnych okolností by mal byť cez čiaru čiapku, ale je možné ju nastaviť vyššie ako pri tradičných 80 kvôli väčším obrazovkám, ktoré dnes vývojári používajú.
  • Nakoniec, keďže veľa výrazov sa nezmestí do jedného riadku, musíme ich dôsledne zlomiť:
    • Volanie metódy prerušenia po čiarke
    • Koncové výrazy pred operátorom
    • Odsadenie zalomených riadkov pre lepšiu čitateľnosť (tu v Baeldungu uprednostňujeme dve medzery)

Pozrime sa na príklad:

Zoznam customerIds = customer.stream () .map (customer -> customer.getCustomerId ()) .collect (Collectors.toCollection (ArrayList :: new));

5.6. Parametre metódy

Parametre sú nevyhnutné pre fungovanie metód podľa špecifikácie. Ale, dlhý zoznam parametrov môže niekomu sťažiť čítanie a porozumenie kódu. Kde by sme teda mali nakresliť čiaru? Poďme pochopiť najlepšie postupy, ktoré nám môžu pomôcť:

  • Pokúste sa obmedziť počet parametrov, ktoré metóda akceptuje, dobrou voľbou môžu byť tri parametre
  • Ak to vyžaduje viac ako odporúčaných parametrov, zvážte refaktorizáciu metódy. Dlhý zoznam parametrov tiež naznačuje, že metóda môže robiť viac vecí
  • Môžeme zvážiť zoskupenie parametrov do vlastných typov, ale musíme byť opatrní, aby sme nevyložili nesúvisiace parametre do jedného typu
  • Nakoniec, aj keď by sme mali tento návrh použiť na posúdenie čitateľnosti kódu, nesmieme byť o ňom pedantní

Pozrime sa na príklad:

public boolean setCustomerAddress (String firstName, String lastName, String streetAddress, String city, String zipCode, String state, String country, String phoneNumber) {} // Ako je uvedené nižšie, môže sa to znova zmeniť, aby sa zvýšila čitateľnosť verejných boolean setCustomerAddress (adresa) {}

5.7. Napevno

Pevne zakódované hodnoty v kóde môžu často viesť k mnohým vedľajším účinkom. Napríklad môže to viesť k duplicite, čo sťažuje zmeny. Ak musia byť hodnoty dynamické, môže to často viesť k nežiaducemu správaniu. Vo väčšine prípadov je možné pevne zakódované hodnoty refaktorovať jedným z nasledujúcich spôsobov:

  • Zvážte nahradenie konštantami alebo enummi definovanými v prostredí Java
  • Môžete tiež nahradiť konštanty definované na úrovni triedy alebo v samostatnom súbore triedy
  • Ak je to možné, nahraďte ich hodnotami, ktoré je možné zvoliť z konfigurácie alebo prostredia

Pozrime sa na príklad:

private int storeClosureDay = 7; // Toto je možné refaktorovať, aby sa použila konštanta z Java private int storeClosureDay = DayOfWeek.SUNDAY.getValue ()

Ani v tomto prípade neexistujú prísne pokyny, ktoré by sa mali dodržiavať. Musíme si však byť vedomí skutočnosti, že niektorí si tento kód budú musieť neskôr prečítať a udržiavať ho. Mali by sme zvoliť dohovor, ktorý nám vyhovuje, a byť v ňom dôslední.

5.8. Poznámky k kódu

Komentáre ku kódu môžu byť prospešné pri čítaní kódu na pochopenie netriviálnych aspektov. Zároveň je potrebné dbať na to nezahrnúť do komentárov zrejmé veci. To môže nadúvať komentáre, čo sťažuje čítanie príslušných častí.

Java umožňuje dva typy komentárov: poznámky k implementácii a poznámky k dokumentácii. Majú tiež rôzne účely a rôzne formáty. Poďme im lepšie porozumieť:

  • Dokumentácia / Komentáre JavaDoc
    • Toto publikum je používateľom kódovej základne
    • Podrobnosti sú zvyčajne bez implementácie a zameriavajú sa viac na špecifikáciu
    • Zvyčajne užitočné nezávisle od kódovej základne
  • Implementácia / blokovanie komentárov
    • Publikum je vývojárom pracujúcim na kódovej základni
    • Podrobnosti sú špecifické pre implementáciu
    • Zvyčajne užitočné spolu s kódovou základňou

Ako ich teda máme optimálne využiť, aby boli užitočné a kontextové?

  • Komentáre by mali iba dopĺňať kód, ak nie sme schopní porozumieť kódu bez komentárov, je možné, že ho budeme musieť prehodnotiť
  • Blokové komentáre by sme mali používať zriedka, možno na popísanie netriviálnych rozhodnutí o dizajne
  • Poznámky JavaDoc by sme mali používať pre väčšinu našich tried, rozhraní, verejných a chránených metód
  • Všetky komentáre by mali byť dobre formulované a mali by byť čitateľne správne odsadené

Pozrime sa na príklad zmysluplného komentára k dokumentácii:

/ ** * Táto metóda slúži na pridanie novej adresy zákazníka. * Upozorňujeme však, že na jeden poštový kód * umožňuje iba jednu adresu. Toto teda prepíše každú predchádzajúcu adresu rovnakým poštovým smerovacím číslom *. * * @param address adresa, ktorá sa má pridať pre existujúceho zákazníka * / / * * Táto metóda využíva vlastnú implementáciu metódy equals *, aby sa zabránilo duplikácii adresy s rovnakým PSČ. * / public addCustomerAddress (adresa) {}

5.9. Protokolovanie

Každý, kto niekedy vložil svoje ruky do produkčného kódu na ladenie, v určitom okamihu túžil po ďalších protokoloch. The dôležitosť guľatiny nemožno príliš zdôrazniť pri vývoji všeobecne a najmä pri údržbe.

V Jave existuje veľa knižníc a rámcov na protokolovanie, vrátane SLF4J, Logback. Aj keď v protokole robia protokolovanie dosť triviálnym, je potrebné venovať pozornosť osvedčeným postupom protokolovania. Inak vykonané ťaženie sa môže namiesto akejkoľvek pomoci ukázať ako nočná mora údržby. Prejdime si niektoré z týchto najlepších postupov:

  • Vyvarujte sa nadmernému protokolovaniu. Zamyslite sa, aké informácie by mohli pomôcť pri riešení problémov
  • Úrovne protokolu vyberajte s rozumom, možno budeme chcieť povoliť úrovne protokolov selektívne pri výrobe
  • S kontextovými údajmi v správe protokolu buďte veľmi jasní a popisní
  • Použite externé nástroje na sledovanie, agregáciu a filtrovanie správ protokolu pre rýchlejšiu analýzu

Pozrime sa na príklad popisného protokolovania so správnou úrovňou:

logger.info (String.format ("Nový zákazník bol vytvorený s ID zákazníka:% s", id));

6. Je to všetko?

Zatiaľ čo predchádzajúca časť zdôrazňuje niekoľko konvencií o formátovaní kódu, nie sú to jediné, o ktorých by sme mali vedieť a zaujímať ich. Čiteľný a udržiavateľný kód môže ťažiť z veľkého množstva ďalších osvedčených postupov, ktoré sa časom zhromaždili.

Možno sme sa s nimi časom stretli ako s vtipnými skratkami. Oni v podstate zachytiť poznatky ako jeden súbor alebo ako súbor zásad, ktoré nám môžu pomôcť napísať lepší kód. Upozorňujeme však, že by sme nemali nasledovať všetky iba preto, že existujú. Výhody, ktoré poskytujú, sú väčšinou úmerné veľkosti a zložitosti kódovej základne. Pred prijatím akejkoľvek zásady musíme mať prístup k našej základni kódov. A čo je dôležitejšie, musíme s nimi zostať v súlade.

6.1. PEVNÝ

SOLID je mnemotechnická skratka, ktorá vychádza z piatich princípov stanovených pre zápis zrozumiteľného a udržiavateľného softvéru:

  • Zásada jedinej zodpovednosti: Každý rozhranie, trieda alebo metóda, ktoré definujeme, by mali mať jasne definovaný cieľ. V zásade by malo ideálne byť robiť jednu vec a robiť to dobre. To efektívne vedie k menším metódam a triedam, ktoré sú tiež testovateľné.
  • Princíp otvorenosti a zatvorenia: Kód, ktorý napíšeme, by mal byť v ideálnom prípade otvorené pre rozšírenie, ale zatvorené pre úpravu. Čo to v skutočnosti znamená, že trieda by mala byť napísaná takým spôsobom, aby ju nebolo potrebné upravovať. Mal by však umožňovať zmeny dedením alebo zložením.
  • Zásada substitúcie Liskov: Táto zásada tvrdí, že je každá podtrieda alebo odvodená trieda by mala byť nahraditeľná svojou materskou alebo základnou triedou. To pomáha pri znižovaní prepojenia v kódovej základni, a tým zlepšuje opätovnú použiteľnosť naprieč.
  • Princíp segregácie rozhrania: Implementácia rozhrania je spôsob, ako zabezpečiť pre našu triedu špecifické správanie. Avšak trieda nesmie vyžadovať implementáciu metód, ktoré nevyžaduje. Toto od nás vyžaduje, aby sme definovali menšie a viac zamerané rozhrania.
  • Princíp inverzie závislostí: Podľa tohto princípu triedy by mali závisieť iba od abstrakcií a nie od ich konkrétnych implementácií. To v skutočnosti znamená, že trieda by nemala byť zodpovedná za vytváranie inštancií pre svoje závislosti. Takéto závislosti by mali byť vložené do triedy.

6.2. DRY & KISS

DRY znamená „Don's Repeat Yourself“. Táto zásada tvrdí, že kus kódu by sa nemal opakovať v celom softvéri. Dôvodom tohto princípu je zníženie duplikácie a zvýšenie opätovnej použiteľnosti. Upozorňujeme však, že by sme mali byť opatrní pri prijímaní toho príliš doslovne. Niektoré duplikácie môžu skutočne zlepšiť čitateľnosť a udržiavateľnosť kódu.

KISS znamená „Keep It Simple, Stupid“. Táto zásada tvrdí, že mali by sme sa snažiť udržiavať kód čo najjednoduchší. To umožňuje ľahké pochopenie a údržbu v priebehu času. Podľa niektorých vyššie spomenutých princípov, ak budeme mať svoje triedy a metódy sústredené a malé, povedie to k jednoduchšiemu kódu.

6.3. TDD

TDD znamená „Test Driven Development“. Toto je programátorská prax, ktorá od nás vyžaduje, aby sme napísali akýkoľvek kód, iba ak zlyháva automatizovaný test. Preto musíme začať s vývojom automatizovaných testov. V Jave existuje niekoľko rámcov na písanie automatizovaných jednotkových testov, ako sú JUnit a TestNG.

Výhody takejto praxe sú obrovské. To vedie k softvéru, ktorý vždy funguje podľa očakávaní. Ako vždy začíname testami, postupne pridávame pracovný kód po malých častiach. Tiež pridáme kód, iba ak nový alebo niektorý zo starých testov zlyhá. Čo znamená, že vedie tiež k opakovanému použitiu.

7. Nástroje pomoci

Písanie čistého kódexu nie je len otázkou zásad a postupov, ale je to aj osobný zvyk. Máme tendenciu rásť ako lepší vývojári, keď sa učíme a prispôsobujeme sa. Aby sme však udržali konzistentnosť vo veľkom tíme, musíme si tiež nacvičiť určité presadzovanie. Zákonníka recenzie boli vždy skvelým nástrojom na udržanie konzistencie a pomôcť vývojárom rásť prostredníctvom konštruktívnej spätnej väzby.

Počas kontroly kódu však nevyhnutne nemusíme všetky tieto princípy a najlepšie postupy overovať manuálne. Freddy Guime z Java OffHeap neustále hovorí o hodnote automatizácie niektorých kontrol kvality, aby nakoniec dosiahli určitú hranicu s kvalitou kódu.

Existujú niekoľko nástrojov dostupných v ekosystéme Java, ktoré minimálne časť týchto zodpovedností odoberajú kontrolórom kódov. Pozrime sa, čo sú niektoré z týchto nástrojov:

  • Formátory kódu: Väčšina populárnych editorov kódu Java, vrátane Eclipse a IntelliJ, umožňuje automatické formátovanie kódu. Môžeme použiť predvolené pravidlá formátovania, prispôsobiť ich alebo ich nahradiť vlastnými pravidlami formátovania. Toto sa stará o veľa konvencií štrukturálneho kódu.
  • Nástroje statickej analýzy: Existuje niekoľko nástrojov na analýzu statického kódu pre Javu, vrátane SonarQube, Checkstyle, PMD a SpotBugs. Majú bohatú sadu pravidiel, ktoré je možné použiť tak, ako sú, alebo prispôsobiť ich pre konkrétny projekt. Sú vynikajúci pri zisťovaní množstva pachov kódu, ako sú porušenia konvencií pomenovania a únik zdrojov.

8. Záver

V tomto tutoriáli sme si prešli dôležitosťou princípov a charakteristík čistého kódovania, ktoré vykazuje čistý kód. Videli sme, ako prijať niektoré z týchto princípov v praxi, ktoré sa vyvíjajú v prostredí Java. Diskutovali sme tiež o ďalších osvedčených postupoch, ktoré pomáhajú udržiavať kód čitateľný a udržiavateľný v priebehu času. Nakoniec sme diskutovali o niektorých dostupných nástrojoch, ktoré nám v tomto snažení pomáhajú.

Ak to zhrnieme, je dôležité poznamenať, že všetky tieto princípy a postupy slúžia na to, aby bol náš kód čistejší. Toto je subjektívnejší pojem, a preto sa musí hodnotiť kontextovo.

Aj keď existuje veľa súborov pravidiel, ktoré je možné prijať, musíme si byť vedomí svojej vyspelosti, kultúry a požiadaviek. Možno budeme musieť prispôsobiť alebo, samozrejme, úplne vymyslieť nový súbor pravidiel. Nech je to však akýkoľvek prípad, je dôležité zostať v organizácii konzistentný, aby ste mohli ťažiť z výhod.


$config[zx-auto] not found$config[zx-overlay] not found