9 pravila za pisanje boljeg koda
Opšti IT PROMO

9 pravila za pisanje boljeg koda

11.06.2021. · 4 min

Object Calisthenics predstavlja vežbe u programiranju, koje se sastoje od 9 pravila.

Pokušavajući da pratiš ova pravila što je više moguće, spontano ćeš promeniti način pisanja koda. Svakako , to ne znači da moraš stalno da pratiš sva pravila svo vreme.

PRAVILA:

  1. Samo jedan nivo indentacije po metodu
  2. Don’t Use The ELSE Keyword
  3. Wrap All Primitives And Strings
  4. First Class Collections
  5. One Dot Per Line
  6. Don’t Abbreviate
  7. Keep All Entities Small
  8. No Classes With More Than Two Instance Variables
  9. No Getters/Setters/Properties

ONLY ONE LEVEL OF INDENTATION PER METHOD

Imati više od jednog nivoa indentacije se smatra lošim po čitljivost i održavanje koda.

Nije lako razumeti kod bez da ga izvršavamo u glavi korak po korak, posebno ako postoji petlja unutar petlje,ili ako ima više uslova sa više promenjivih.

Prateći ovo pravilo, kod će biti podeljen u više različitih funkcija. Broj linija neće biti smanjen, ali će se čitljivost popraviti značajno.

DON’T USE THE ELSE KEYWORD

If-Else slučajevi su teški za čitanje, i ne donese nikakvu vrednost našem kodu.

Lak način da se ovako nesto promeni je korišćenjem "early return" rešenja.

WRAP ALL PRIMITIVES AND STRINGS

Da bi izbegli Primitive Obsession, sve primitivne vrednost bi trebalo da budu zarobljene u objektima. Ako primitivna promenjiva ima određeno ponašanje (novac, vreme), neophodno je da se ona zarobi.

FIRST CLASS COLLECTIONS

Kolekcije ne bi trebalo da sadrže druge promenjive. Ako postoji kolekcija elemenata i želiš da manipulišeš sa njima, trebalo bi da napraviš klasu koja je namenjena isključivo tome.

Svaka kolekcija dobija svoju klasu, i svo ponašanje za filtere i pravila se nalaze unutar nje.

ONE DOT PER LINE

Pozivi metoda ne bi trebalo da budu "chainovani" (ne odnosi se na Fluent Interfaces i Method Chaining Pattern), sve ostale klase bi trebalo da poštuju ovo pravilo).

Ovo je direktno povezano sa Law of Demeter. Objekti bi trebalo da kontaktiraju samo najbliže prijatelje (objekte).

DON’T ABBREVIATE

Ako pišeš ista imena iznova i iznova, to verovatno znači da postoji code duplication.

Ako je ime klase predugačko, to verovatno znači da ima više od jedne odgovornosti i time narušava SRP.

Imenovanje je veoma bitna stvar, i može da unapredi tvoj kod mnogo. Skraćenice mogu da dovedu do zbunjenosti, jer nije svako upoznat sa njihovim značenjem. Kompenzacija koju imamo nije vredna.

KEEP ALL ENTITIES SMALL

“Nijedna klasa preko 50 linja i paket preko 10 fajlova.”

Ideja iza ovog pravila je da su dugački fajlovi teški za čitanje, teški za razumevanje i teški za manipulisanje. Ovo pravilo nije baš lako za primeniti (u jezicima kao sto je PHP gotovo nemoguće, ali može biti prilagođeno), ali po mom mišljenju klase/funkcije mogu biti donekle kratke i ovo pravilo primenjeno donekle, ali poštovanje ovih brojeva (50 linija, 10 fajlova) nije apsolutno neophodno, sve dok klase nisu više od 100-200 linija (pogotovo u PHP-u).

NO CLASSES WITH MORE THAN TWO INSTANCE VARIABLES

Ovo pravilo se direktno naslanja na pravilo broj 3 (WRAP ALL PRIMITIVES AND STRINGS), doprinosi koheziji, i boljoj enkapsulaciji. Glavna ideja je da se razlikuju dve vrste klasa, one koje održavaju stanje pojedinačne promenjive, i one koje upravljaju sa dve (ili više) različitih promenjivih. 2 je zamišljeni izbor koji prisiljava na deljenje tvojih klasa. Moje mišljenje je da ne moraju biti tačno dve promenjive, ali da bi trebalo da držimo broj promenjljivih na niskom broju, i može biti napisan slično sledećem primeru:

NO GETTERS/SETTERS/PROPERTIES

Sve dok ne koristiš rezultat "accessora" (gettera) da bi napravio odluku izvan objekta, korišćenje gettera bi trebalo da bude u redu.

Sve odluke koje su donete na osnovu stanja objekta bi trebalo da se nalaze u samom objektu. To je razlog zbog koga su "getteri" i "setteri" loši, jer krše Open/Closed Principle direktno.

Na kraju krajeva, neka pravila su veoma laka za korišćenje i unaprediće tvoj kod mnogo, neka druga nisu baš najlakša za korišćenje. Na tebi je da odlučiš da li ćeš se njima koristiti ili ne i da ih vežbaš u slobodno vreme ako se ne osećaš komforno.

 

Ukoliko želiš da saznaš više informacija o kompaniji, beneficijama, plati, kao i iskustva zaposlenih i kako izgleda razgovor za posao, poseti profil poslodavca na IT Insajderu: LINK."

(3 osobe su glasale, prosečna ocena: 5)

1 komentar

  1. ReactDOMServerIntegrationHooks-test.js
    ReactDOMServerIntegrationHooks-test.js jun 15, 2021 u 02:02 · Odgovori

    Ok. Ali, moj pogled na temu je takav, da je to nešto što očekujem da bude podešeno prema projektu i njegovom ekosistemu. Linter i formater bi osigurali navedeno. Da je do mene - neka od pravila bila bi:* da se razumeju logika poslovanja, pojmovi, i da se znanje usavršava* voditi dvosedmičnu diskusiju da li su se pojavili "anti-pattern" kandidati u kodu, i da se to "prepegla"* navedeni linter i formater da se doteruju, to je živa stvar* osvrnuti se na postignute funkcionalnosti i razumeti šta je od važnosti za sam biznis

Ostavi komentar

Odgovori

Greška

Popuni sva obavezna polja!
Copyright © 2021 ·
Made with in Subotica.
Sadržaj sajta je u vlasništvu kompanije HelloWorld. Zabranjeno je njegovo preuzimanje bez dozvole.
Uspešno
Neuspešno urađena operacija
Prijavi se u svoj nalog
Zaboravljena šifra?

Nisi registrovani korisnik? Napravi nalog ili se prijavi putem društvenih mreža.



Prijava putem društvenih mreža

Kontaktiraj nas

Potvrdi

Greška