Tiszta kódolás Java-ban

1. Áttekintés

Ebben az oktatóanyagban áttekintjük a tiszta kódolási elveket. Megértjük azt is, hogy miért fontos a tiszta kód, és hogyan lehet ezt elérni a Java-ban. Továbbá meglátjuk, hogy vannak-e olyan eszközök, amelyek segítenek bennünket.

2. Mi az a Clean Code?

Tehát, mielőtt áttekintenénk a tiszta kód részleteit, értsük meg, mit értünk a tiszta kód alatt. Őszintén szólva erre nem lehet egy jó válasz. A programozás során egyes aggályok átfognak, és ezért általános elveket eredményeznek. De akkor minden programozási nyelv és paradigma bemutatja saját árnyalatkészletét, amely felhatalmaz minket arra, hogy megfelelő gyakorlatokat alkalmazzunk.

Széles körben, A tiszta kód összefoglalható olyan kódként, amelyet bármely fejlesztő el tud olvasni és könnyen megváltoztathat. Bár ez a koncepció túlegyszerűsítésének tűnhet, később az oktatóanyagban látni fogjuk, hogyan épül fel ez. Bárhol, ahol a tiszta kódról hallunk, találkozhatunk Martin Fowlerre való utalással. Így írja le a tiszta kódot az egyik helyen:

Bármilyen bolond írhat olyan kódot, amelyet a számítógép megérthet. A jó programozók olyan kódot írnak, amelyet az emberek megérthetnek.

3. Miért kell törődnünk a tiszta kóddal?

A tiszta kód írása éppúgy személyes szokás, mint hozzáértés kérdése. Fejlesztőként a tapasztalatok és az ismeretek révén idővel növekszünk. De fel kell tennünk a kérdést, miért kellene mégis befektetnünk a tiszta kód kifejlesztésébe? Megállapítottuk, hogy mások valószínűleg könnyebben olvassák a kódunkat, de vajon ez az ösztönzés elég-e? Találjuk ki!

A tiszta kódolási elvek sok kívánatos cél elérését segítik elő az általunk gyártani kívánt szoftverrel kapcsolatban. Menjünk át rajtuk, hogy jobban megértsük:

  • Karbantartható Codebase: Bármely általunk fejlesztett szoftver élettartama él, ezért ebben az időszakban változtatásokat és általános karbantartást igényel. Tiszta kód segíthet olyan szoftver fejlesztésében, amelyet könnyű megváltoztatni és karbantartani túlóra.
  • Könnyebb hibaelhárítás: A szoftver nem kívánt viselkedést mutathat a különféle belső vagy külső tényezők miatt. A javítások és az elérhetőség szempontjából gyakran gyors fordulatot igényel. Tiszta kódolási elvekkel kifejlesztett szoftver könnyebb elhárítani a problémákat.
  • Gyorsabb beszállás: A szoftver élettartama alatt sok fejlesztő fogja létrehozni, frissíteni és karbantartani, a fejlesztők különböző időpontokban csatlakoznak hozzá. Ehhez szükség van gyorsabb beszállás a termelékenység magas szinten tartása érdekében, és a tiszta kód segít elérni ezt a célt.

4. A Clean Code jellemzői

A tiszta kódolási elvekkel írt kódbázisok számos olyan tulajdonsággal rendelkeznek, amelyek megkülönböztetik őket. Menjünk át a következő jellemzők közül:

  • Összpontosított: Egy darab kódot kell írni egy adott probléma megoldására. Nem szabad semmit tennie, ami szigorúan nem kapcsolódik az adott probléma megoldásához. Ez a kódbázis absztrakciójának minden szintjére vonatkozik, mint a módszer, osztály, csomag vagy modul.
  • Egyszerű: Ez egyértelműen a tiszta kód legfontosabb és gyakran figyelmen kívül hagyott jellemzője. A szoftver a tervezésnek és a megvalósításnak a lehető legegyszerűbbnek kell lennie, amely segíthet a kívánt eredmények elérésében. A kódbázis bonyolultságának növekedése hibára hajlamossá, nehezen olvashatóvá és fenntarthatóvá teszi őket.
  • Tesztelhető: A tiszta kódnak, bár egyszerű, meg kell oldania a problémát. Kell lennie intuitív és könnyen tesztelhető a kódbázis, lehetőleg automatizált módon. Ez segít meghatározni a kódbázis viselkedését és megkönnyíti annak megváltoztatását anélkül, hogy bármi is megtörne.

Ezek segítenek az előző szakaszban tárgyalt célok elérésében. Előnyös, ha később a refaktorhoz képest ezeket a jellemzőket szem előtt tartva kezdjük el fejleszteni. Ez alacsonyabb teljes szoftverköltséget eredményez a szoftver életciklusában.

5. Tiszta kódolás Java-ban

Most, hogy elég hátteret éltünk át, nézzük meg, hogyan építhetjük be a tiszta kódolási elveket a Java-ba. A Java rengeteg bevált gyakorlatot kínál, amelyek segíthetnek a tiszta kódírásban. Különböző kategóriákba soroljuk őket, és megértjük, hogyan kell tiszta mintákat írni kódmintákkal.

5.1. Projekt felépítése

Bár a Java nem érvényesít semmilyen projektstruktúrát, A forrásfájlok, tesztek, konfigurációk, adatok és más kódtermékek rendezése érdekében mindig hasznos következetes mintát követni. A Maven, a Java népszerű építőeszköze, egy adott projektstruktúrát ír elő. Lehet, hogy nem használjuk a Maven-t, de mindig jó ragaszkodni a konvencióhoz.

Nézzük meg azokat a mappákat, amelyek létrehozását Maven javasolja:

  • src / main / java: Forrásfájlokhoz
  • src / main / resources: Erőforrásfájlokhoz, például a tulajdonságokhoz
  • src / test / java: Tesztforrás fájlokhoz
  • src / test / resources: Teszt erőforrás fájlokhoz, például tulajdonságokhoz

Ehhez hasonlóan vannak más népszerű projektstruktúrák, mint például a Bazel, amelyet a Java javasol, és az igényeink és a közönségünk szerint kell választanunk egyet.

5.2. Elnevezési

Következő a névadási konvenciók nagyban hozzájárulhatnak a kódunk olvashatóságához és így karbantarthatóságához. Rod Johnson, a Spring készítője hangsúlyozza a tavaszi elnevezések fontosságát:

"... ha tudod, mit csinál valami, akkor nagyon jó esélyed van kitalálni a tavaszi osztály nevét vagy felületét hozzá ..."

A Java előír egy szabályrendszert, amelyet be kell tartani, amikor bármit elneveznek a Java-ban. A jól kialakított név nemcsak a kód olvasásában segít, hanem sokat elárul a kód szándékáról is. Vegyünk néhány példát:

  • Osztályok: Az osztály az objektum-orientált fogalmak szempontjából tervrajz azoknak az objektumoknak, amelyek gyakran valós tárgyakat képviselnek. Ezért értelmes a főneveket használni az osztályok kellő megnevezésére:
nyilvános osztályú ügyfél {}
  • Változók: A Java változók rögzítik az osztályból létrehozott objektum állapotát. A változó nevének világosan le kell írnia a változó szándékát:
public class Ügyfél {private String ügyfélNév; }
  • Mód: A Java módszerei mindig az osztályok részét képezik, és ezért általában az osztályból létrehozott objektum állapotára vonatkozó műveletet jelentenek. Ezért hasznos módszereket megnevezni igék használatával:
public class Ügyfél {private String ügyfélNév; public String getCustomerName () {return this.customerName; }}

Míg csak arról beszéltünk, hogy miként nevezhetünk egy azonosítót a Java-ban, kérjük, vegye figyelembe, hogy vannak további bevált gyakorlatok, például a teve tokja, amelyeket az olvashatóság érdekében be kell tartanunk. Több konvenció lehet a felületek, enumok, konstansok elnevezésével kapcsolatban is.

5.3. Forrás fájl felépítése

A forrásfájl különböző elemeket tartalmazhat. Míg a Java a fordító valamilyen struktúrát érvényesít, nagy része folyékony. De egy adott sorrend betartása, amelyben az elemeket egy forrásfájlba helyezi, jelentősen javíthatja a kód olvashatóságát. Számos népszerű stílusú útmutató ihletet meríthet, mint például a Google, a másik pedig a Spring.

Lássuk, hogyan kell kinéznie a forrásfájl elemeinek tipikus sorrendjének:

  • Csomagkivonat
  • Nyilatkozatok importálása
    • Minden statikus import
    • Minden nem statikus behozatal
  • Pontosan egy felső szintű osztály
    • Osztályváltozók
    • Példányváltozók
    • Kivitelezők
    • Mód

A fentieken kívül a módszerek funkcionalitásuk vagy hatókörük alapján csoportosíthatók. Nincs egy jó egyezmény, és az ötletnek meg kell lennie egyszer döntött, majd következetesen követte.

Lássunk egy jól formázott forrásfájlt:

# /src/main/java/com/baeldung/application/entity/Customer.java csomag com.baeldung.application.entity; import java.util.Date; public class Ügyfél {private String ügyfélNév; privát Date joininingDate; public Ügyfél (String customerName) {this.customerName = customerName; this.joiningDate = új dátum (); } public String getCustomerName () {return this.customerName; } public Date getJoiningDate () {return this.joiningDate; }}

5.4. Fehérek

Mindannyian tudjuk, hogy a rövid bekezdések elolvasása és megértése könnyebb, mint egy nagy szövegtömb. Nem nagyon különbözik a kódolvasásról sem. A jól elhelyezett és következetes szóközök és az üres sorok javíthatják a kód olvashatóságát.

Az ötlet az, hogy logikai csoportosításokat vezessenek be a kódba, amelyek segíthetnek a gondolkodási folyamatok megszervezésében, miközben megpróbálják átolvasni. Itt egyetlen szabályt kell elfogadni, hanem egy általános iránymutatást és az eredendő szándékot, hogy az olvashatóság középpontjában maradjon:

  • Két üres sor a statikus blokkok, mezők, konstruktorok és belső osztályok megkezdése előtt
  • Egy üres sor egy többsoros metódus aláírás után
  • Egyetlen szóköz, amely elválasztja a fenntartott kulcsszavakat, például ha nyitott zárójelben találja
  • Egyetlen szóköz, amely elválasztja a fenntartott kulcsszavakat, mint a többi, elkap egy zárójelben

Az itt szereplő felsorolás nem teljes, de előnyt kell jelentenünk arra, hogy továbblépjünk.

5.5. Behúzás

Bár meglehetősen triviális, szinte minden fejlesztő kezeskedik a tény mellett egy jól behúzott kód sokkal könnyebben olvasható és érthető. A kód behúzására nincs egyetlen egyezmény a Java-ban. A legfontosabb itt egy népszerű egyezmény elfogadása, vagy egy magánmeghatározás meghatározása, majd az egész szervezeten belüli következetes követése.

Nézzük meg néhány fontos behúzási kritériumot:

  • Tipikus legjobb gyakorlat négy szóköz, egy behúzás egység használata. Felhívjuk figyelmét, hogy néhány irányelv szóközök helyett tabulátort javasol. Bár itt nincs abszolút legjobb gyakorlat, a kulcs továbbra is a következetesség marad!
  • Normális esetben a vonalhossz felett felső határnak kell lennie, de ezt a fejlesztők által használt nagyobb képernyőknek köszönhetően magasabbra lehet állítani, mint a hagyományos 80-at.
  • Végül, mivel sok kifejezés nem fér el egyetlen sorban, következetesen meg kell bontanunk őket:
    • A Break módszer vessző után hív
    • Törd a kifejezéseket egy operátor előtt
    • Behúzott vonalak a jobb olvashatóság érdekében (mi itt, Baeldungnál két szóközt preferálunk)

Lássunk egy példát:

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

5.6. Módszer Paraméterek

A paraméterek elengedhetetlenek ahhoz, hogy a módszerek a specifikáció szerint működjenek. De, a paraméterek hosszú listája megnehezítheti valakinek a kód olvasását és megértését. Szóval, hol kell meghúznunk a határt? Értsük meg a legjobb gyakorlatokat, amelyek segítségünkre lehetnek:

  • Próbáljon korlátozni a módszer által elfogadott paraméterek számát, három paraméter lehet egy jó választás
  • Fontolja meg a módszer visszafejlesztését, ha az ajánlottnál többet igényel, általában egy hosszú paraméterlista is jelzi, hogy a módszer több dolgot is végezhet
  • Megfontolhatjuk a paraméterek egyedi típusokba történő csomagolását, de vigyáznunk kell, hogy a nem kapcsolódó paramétereket egyetlen típusba dobjuk
  • Végül, bár ezt a javaslatot kell használnunk a kód olvashatóságának megítélésére, nem szabad pedánsnak lennünk vele

Lássunk erre egy példát:

public boolean setCustomerAddress (String firstName, String lastName, String streetAddress, String city, String zipCode, String state, String country, String phoneNumber) {} // Ezt az alábbiak szerint lehet átalakítani az olvashatóság növelése érdekében a public boolean setCustomerAddress (Address address) {}

5.7. Keménykódolás

A kódban szereplő hardcoding értékek gyakran több mellékhatáshoz vezethetnek. Például, ez megkettőzéshez vezethet, ami megnehezíti a változást. Ez gyakran nemkívánatos viselkedéshez vezethet, ha az értékeknek dinamikusnak kell lenniük. Az esetek többségében a kemény kódolású értékeket a következő módszerek egyikével lehet átalakítani:

  • Fontolja meg a Java-ban definiált konstansokkal vagy enumokkal való helyettesítést
  • Vagy módosíthatja az osztály szintjén vagy egy külön osztályfájlban definiált konstansokkal
  • Ha lehetséges, cserélje ki a konfigurációból vagy a környezetből kiválasztható értékekre

Lássunk egy példát:

private int storeClosureDay = 7; // Ezt úgy lehet átalakítani, hogy a Java privát int storeClosureDay = DayOfWeek.SUNDAY.getValue () konstansát használjuk.

Ismét nincs szigorú irányelv, amelyet be kellene tartani. De tudatában kell lennünk annak a ténynek, hogy néhányuknak később el kell olvasnia és karbantartania ezt a kódot. Olyan konvenciót kell választanunk, amely megfelel nekünk, és következetesnek kell lennünk abban.

5.8. Kód megjegyzések

Kód megjegyzések lehetnek előnyös a kód olvasása közben a nem triviális szempontok megértése érdekében. Ugyanakkor ügyelni kell arra ne tartalmazzon nyilvánvaló dolgokat a megjegyzésekben. Ez felfújhatja a megjegyzéseket, és megnehezíti a vonatkozó részek elolvasását.

A Java kétféle megjegyzést tesz lehetővé: Megjegyzések a megvalósításhoz és a dokumentációhoz. Különböző célokkal és formátumokkal rendelkeznek. Értsük meg jobban őket:

  • Dokumentáció / JavaDoc megjegyzések
    • A közönség itt a kódbázis felhasználója
    • Az itt található részletek jellemzően megvalósításmentesek, jobban a specifikációra összpontosítva
    • Tipikusan hasznos, függetlenül a kódbázistól
  • Végrehajtás / blokk megjegyzések
    • A közönség itt a kódbázison dolgozó fejlesztők
    • A részletek itt megvalósítás-specifikusak
    • Tipikusan a kódbázissal együtt hasznos

Szóval, hogyan kell optimálisan használni őket, hogy hasznosak és kontextusban legyenek?

  • A megjegyzéseknek csak akkor kell kiegészíteniük a kódot, ha nem tudjuk megérteni a kódot megjegyzések nélkül, talán át kell alakítanunk
  • Ritkán kell használnunk blokkmegjegyzéseket, esetleg nem triviális tervezési döntések leírására
  • A legtöbb osztályunkhoz, felületünkhöz, nyilvános és védett módszereinkhez JavaDoc megjegyzéseket kell használnunk
  • Minden megjegyzésnek jól formázottnak kell lennie, az olvashatóság érdekében megfelelő behúzással

Lássunk egy példát az értelmes dokumentációs megjegyzésre:

/ ** * Ez a módszer új címet kíván adni az ügyfél számára. * Ne feledje azonban, hogy irányítószámonként csak egy címet engedélyez. Ezért ez felülír minden korábbi címet ugyanazzal az irányítószámmal. * * @param cím egy meglévő ügyfél számára hozzáadandó cím * / / * * Ez a módszer az egyenlő * metódus egyéni megvalósítását használja az azonos irányítószámú cím megkettőzésének elkerülésére. * / public addCustomerAddress (cím címe) {}

5.9. Fakitermelés

Aki valaha is rátette a kezét a gyártási kódra a hibakereséshez, egy bizonyos napra több naplóra vágyott. A A rönkök fontosságát nem lehet túl hangsúlyozni a fejlesztésben általában és különösen a karbantartásban.

A Java-ban rengeteg könyvtár és keretrendszer van naplózásra, beleértve az SLF4J-t és a Logback-et. Míg a naplózást meglehetősen elenyészővé teszik egy kódban, ügyelni kell a naplózás bevált gyakorlataira. Az egyébként elvégzett fakitermelés minden segítség helyett karbantartási rémálommá válhat. Menjünk át a következő bevált gyakorlatok közül:

  • Kerülje a túlzott naplózást, gondolja át, milyen információk lehetnek segítséget a hibaelhárításban
  • Bölcsen válassza a naplószinteket, érdemes lehet szelektíven engedélyezni a naplószinteket a gyártás során
  • Legyen nagyon világos és leíró a naplóüzenetben szereplő kontextuális adatokkal
  • Használjon külső eszközöket a naplóüzenetek nyomon követéséhez, összesítéséhez és szűréséhez a gyorsabb elemzés érdekében

Lássunk egy példát a leíró naplózásra megfelelő szinttel:

logger.info (String.format ("Új ügyfél jött létre ügyfél-azonosítóval:% s", id));

6. Ez az egész?

Míg az előző szakasz több kódformázási konvenciót emel ki, nem csak ezekről kell tudnunk és törődnünk velük. Az olvasható és karbantartható kód számos további bevált gyakorlatot élvezhet, amelyek az idők során felhalmozódtak.

Lehet, hogy idővel vicces betűszavakként találkozhattunk velük. Ők lényegében egyetlen vagy több olyan elvként rögzíti a tanulást, amely segíthet jobb kód megírásában. Ne feledje azonban, hogy nem szabad mindet követni, csak azért, mert léteznek. Legtöbbször az általuk nyújtott előny arányos a kódbázis méretével és összetettségével. Bármely elv elfogadása előtt hozzáférnünk kell a kódalapunkhoz. Ennél is fontosabb, hogy következetesek maradjunk velük.

6.1. SZILÁRD

A SOLID egy mnemonikus betűszó, amely az érthető és karbantartható szoftverek írásához előírt öt alapelvből merít:

  • Egyetlen felelősség elve: Mindegyik az általunk definiált interfésznek, osztálynak vagy módszernek világosan meghatározott célt kell tartalmaznia. Lényegében ideális esetben egy dolgot kellene tennie, és ezt jól tennie. Ez gyakorlatilag kisebb módszerekhez és osztályokhoz vezet, amelyek szintén tesztelhetők.
  • Nyitott-zárt elv: A kód, amelyet írunk, ideális legyen meghosszabbításra nyitott, de módosításra zárt. Ez tulajdonképpen azt jelenti, hogy egy osztályt úgy kell írni, hogy ne kelljen módosítani. Lehetővé kell tennie azonban az öröklés vagy az összetétel útján történő változásokat.
  • Liskov helyettesítés elve: Ez az elv azt állítja minden alosztálynak vagy származtatott osztálynak helyettesíteni kell a szülőjét vagy az alaposztályát. Ez segít csökkenteni a kódbázisban a csatolást, és ezáltal javítani az egész újrafelhasználhatóságát.
  • Interfész elkülönítési elve: Az interfész megvalósítása egyfajta viselkedés biztosítása az osztályunk számára. Azonban, egy osztálynak nem kell olyan módszereket megvalósítania, amelyekre nincs szüksége. Ehhez meg kell tennünk, hogy meghatározzunk kisebb, fókuszáltabb interfészeket.
  • Függőségi inverzió elve: Ezen elv szerint osztályoknak csak az absztrakcióktól kell függeniük, és nem konkrét megvalósításuktól. Ez gyakorlatilag azt jelenti, hogy egy osztálynak nem kell felelősséget vállalnia a függőségükhöz tartozó példányok létrehozásáért. Inkább ilyen függőségeket kell beadni az osztályba.

6.2. SZÁRAZ ÉS CSISZT

A DRY jelentése: „Don ismételje meg önmagát”. Ez az elv azt állítja egy kóddarabot nem szabad megismételni a szoftverben. Ennek az elvnek az az oka, hogy csökkentse a duplikációt és növelje az újrafelhasználhatóságot. Felhívjuk azonban a figyelmet arra, hogy óvatosnak kell lennünk, ha ezt túl szó szerint elfogadjuk. Bizonyos duplikációk valóban javíthatják a kódok olvashatóságát és karbantarthatóságát.

A KISS jelentése: „Tartsd egyszerű, hülye”. Ez az elv azt állítja meg kell próbálnunk a kódot a lehető legegyszerűbben tartani. Ez megkönnyíti az idő múlásával a megértést és fenntartást. A korábban említett elvek némelyikét követve, ha koncentráltan és kicsiben tartjuk osztályainkat és módszereinket, ez egyszerűbb kódhoz vezet.

6.3. TDD

A TDD jelentése „tesztvezérelt fejlesztés”. Ez egy olyan programozási gyakorlat, amely csak akkor kér meg minket, hogy írjunk bármilyen kódot, ha egy automatizált teszt nem sikerül. Ezért muszáj kezdje az automatizált tesztek tervezésének fejlesztésével. A Java-ban számos olyan keretrendszer létezik, amelyek automatizált egységteszteket írnak, például a JUnit és a TestNG.

Az ilyen gyakorlat óriási előnyökkel jár. Ez olyan szoftverhez vezet, amely mindig az elvárásoknak megfelelően működik. Mint mindig tesztekkel kezdjük, apránként hozzáadjuk a munkakódot. Ezenkívül csak akkor adunk hozzá kódot, ha az új vagy a régi tesztek sikertelenek. Ami azt jelenti, hogy újrafelhasználhatósághoz is vezet.

7. Segítség eszközei

A tiszta kód írása nemcsak elvek és gyakorlatok kérdése, hanem személyes szokás is. Hajlamosak vagyunk jobb fejlesztőkké növekedni, ahogy tanulunk és alkalmazkodunk. Ahhoz azonban, hogy egy nagy csapatban megőrizzük az egységességet, gyakorolnunk kell bizonyos végrehajtásokat is. Kód a vélemények mindig is nagyszerű eszköz voltak az egységesség megőrzéséhez és konstruktív visszacsatolással segíti a fejlesztőket.

A kódellenőrzések során azonban nem feltétlenül kell manuálisan érvényesítenünk ezeket az elveket és a bevált gyakorlatokat. Freddy Guime, a Java OffHeap munkatársa arról beszél, hogy mennyire érdemes automatizálni a minőségellenőrzéseket, hogy egy bizonyos küszöböt érjenek el a kódminőséggel.

Vannak számos eszköz elérhető a Java ökoszisztémában, amelyek ezeknek a felelősségeknek legalább egy részét elveszik a kódellenőröktől. Lássuk, mik ezek az eszközök:

  • Kódformázók: A legnépszerűbb Java-kódszerkesztők, köztük az Eclipse és az IntelliJ, lehetővé teszik az automatikus kódformázást. Használhatjuk az alapértelmezett formázási szabályokat, testreszabhatjuk őket, vagy egyedi formázási szabályokkal helyettesíthetjük őket. Ez sok strukturális kódegyezményről gondoskodik.
  • Statikus elemző eszközök: Számos statikus kódelemző eszköz létezik a Java számára, köztük a SonarQube, a Checkstyle, a PMD és a SpotBugs. Gazdag szabályrendszerrel rendelkeznek, amelyek felhasználhatók olyan állapotban vagy testreszabhatóak egy adott projekthez. Kiválóan érzékelik a sok kódszagot, mint a névadási szabályok megsértése és az erőforrások szivárgása.

8. Következtetés

Ebben az oktatóanyagban áttekintettük a tiszta kódolási elvek és jellemzők fontosságát, amelyeket a tiszta kód mutat. Láttuk, hogyan lehet ezeket az elveket a gyakorlatban alkalmazni, amelyek Java-ban fejlődnek. Megvitattunk más bevált gyakorlatokat is, amelyek elősegítik a kód olvasható és karbantartható fenntartását az idő múlásával. Végül megbeszéltük a rendelkezésre álló eszközöket, amelyek segítenek bennünket ebben a törekvésben.

Összefoglalva fontos megjegyezni, hogy mindezek az elvek és gyakorlatok azért vannak, hogy tisztábbá tegyük kódunkat. Ez egy szubjektívebb kifejezés, ezért kontextus szerint kell értékelni.

Noha az elfogadásra számos szabály áll rendelkezésre, tudatában kell lennünk érettségünknek, kultúránknak és követelményeinknek. Előfordulhat, hogy testre kell szabnunk, vagy teljesen új szabályokat kell kidolgoznunk. Bármi is legyen a helyzet, fontos, hogy az egész szervezetben következetes maradjon az előnyök kihasználása érdekében.


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