Vaš kod može mirisati! Kako to popraviti

kodni miris je komad koda ili opći obrazac kodiranja koji izgleda kao da bi mogao ukazivati ​​na dublji problem u cjelokupnoj strukturi i dizajnu baze podataka.

Razmislite o mirisu koda kao bilo kojem znaku koji sugerira da se dio koda treba ponovno popraviti. Nije u tome da je kôd buzan ili ne funkcionalan - često puta, mirisni kod radi sasvim u redu - ali mirisni je kôd često teško održavati i proširiti, što može dovesti do tehničkih problema (posebno na većim projektima).

U ovom ćemo članku istaknuti 10 najčešćih mirisa kodova, na što treba paziti i kako ih deodorizirati. Ako ste novi programer Kako naučiti programiranje bez svakog stresa Kako naučiti programirati bez ikakvog stresa Možda ste se odlučili baviti programiranjem bilo za karijeru ili samo kao hobi. Sjajno! Ali možda se počinjete osjećati preplavljeno. Nije tako sjajno. Evo pomoći da vam olakša putovanje. , izbjegavajte ove i vaš će kôd biti osjetno bolji!

1. Čvrsto spajanje

Problem
Čvrsto spajanje je kada dva objekta toliko ovise o podacima i / ili funkcijama jedan drugoga da mijenjanje jednog zahtijeva promjenu drugog. Kad su dva objekta previše čvrsto povezana, unošenje promjena u kod može biti noćna mora i vjerojatnije je da ćete sa svakom promjenom uvoditi bugove.

Na primjer:

razredni radnik Bike bike = novi Bike (); javna void commute () bike.drive (); 

U ovom su slučaju Worker i Bicikl čvrsto povezani. Što ako jednog dana želite putovati automobilom umjesto bicikla? Morate ući u klasu Worker i zamijeniti sve kodove povezane s biciklom s kodom koji se odnosi na automobil. Neuredan je i sklon greškama.

Rješenje
Spajanje možete otpustiti dodavanjem sloja apstrakcije. U ovom slučaju, klasa Worker ne želi samo voziti bicikle, već i automobile, a možda i kamione, možda čak i skutere. Sve su to vozila, zar ne? Stoga stvorite sučelje vozila, koje vam omogućuje umetanje i zamjenu različitih vrsta vozila po želji:

radnik klase Vozilo u vozilu; javna praznina promjenaVehicle (Vozilo v) vozilo = v;  javna void commute () Vehicle.drive ();  Vozilo za sučelje void drive ();  klase biciklističkih uređaja Vozilo javna void vožnja ()  klasa Automobilski uređaji Vozilo javna void vožnja () 

2. Božje predmete

Problem
Božiji objekt je masivna klasa / modul koji sadrži previše varijabli i funkcija. To “zna previše” i “čini previše,” što je problematično iz dva razloga. Prvo, ostale klase / moduli pretjerano se oslanjaju na ove podatke (usko spajanje). Drugo, cjelokupna struktura programa postaje mutna kako se sve gužva na istom mjestu.

Rješenje
Uzmite Božiji objekt, odvojite njegove podatke i funkcije prema tome koji problemi postoje da bi se riješili, a zatim te grupe pretvorite u objekte. Ako imate Božji objekt, možda vam je to bolje kao sastav mnogih manjih objekata.

Na primjer, pretpostavimo da imate monstruoznu Korisničku klasu:

korisnik klase javno String korisničko ime; javna string lozinka; javna string adresa; javni string string-kod; public int age;… javni niz String getUsername () vrati korisničko ime;  javni void setUsername (string u) korisničko ime = u; 

Možete ga pretvoriti u sastav sljedećeg:

Korisnik klase vjerodajnice; Profil profila;… vjerodajnice klase javno String korisničko ime; javna String lozinka;… javni String getUsername () vrati korisničko ime;  javni void setUsername (string u) korisničko ime = u; 

Sljedeći put kada trebate izmijeniti postupke prijave, ne morate prolaziti kroz masivnu korisničku klasu jer je klasa vjerodajnica upravljivija.!

3. Duge funkcije

Problem
Duga funkcija je upravo ono što zvuči: funkcija koja je predugo rasla. Iako ne postoji određeni broj koliko je redaka koda “predugo” za funkciju, to je jedna od onih stvari za koju znate kad je vidite. Prilična je inačica problema s Božjim objektima užeg opsega - duga funkcija ima previše odgovornosti.

Rješenje
Duge funkcije treba razbiti u mnoge pod-funkcije, gdje je svaka pod-funkcija dizajnirana za obradu s jednim zadatkom ili problemom. U idealnom slučaju izvorna duga funkcija pretvorit će se u popis poziva za podfunkcije, što će kôd biti čistiji i lakši za čitanje.

4. Prekomjerni parametri

Problem
Funkcija (ili konstruktor klase) koja zahtijeva previše parametara problematična je iz dva razloga. Prvo, kôd čini manje čitljivim i čini ga teškim za testiranje. Ali drugo, i što je još važnije, može značiti da je svrha funkcije previše dvosmislena i pokušava se nositi s previše odgovornosti.

Rješenje
Dok “previše” je subjektivan za popis parametara, preporučujemo da se pazite bilo koje funkcije koja ima više od 3 parametra. Naravno, ponekad ima smisla imati jednu funkciju s 5 ili čak 6 parametara, ali samo ako za to postoji stvarno dobar razlog.

Većinu vremena nema niti jedne i kôd bi bilo bolje razbiti tu funkciju na dvije ili više različitih funkcija. Za razliku od “Duge funkcije” miris koda, ovaj se ne može riješiti samo zamjenom koda podfunkcijama - samu funkciju treba podijeliti i podijeliti na odvojene funkcije koje pokrivaju odvojene odgovornosti.

5. Loše imenovani identifikatori

Problem
Nazivi varijabli s jednim ili dva slova. Nespiski nazivi funkcija. Prekomjerno ukrašena imena klasa. Označavanje imena varijabli s njihovom vrstom (npr. B_isZbrojeno je logična varijabla). I što je najgore, miješanje različitih shema imenovanja unutar jedne baze podataka. Sve to rezultira teško čitljivim, teško razumljivim i teško održavajućim kodom.

Rješenje
Odabir dobrih imena za varijable, funkcije i klase teško je naučena vještina. Ako se pridružujete postojećem projektu, prođite kroz njega i pogledajte kako se nazivi postojećih identifikatora. Ako postoji vodič za stil, zapamtite ga i pridržavajte se ga. Za nove projekte razmislite o oblikovanju vlastitog stilskog vodiča i držite se toga.

Općenito, nazivi varijabli trebaju biti kratki, ali opisni. Nazivi funkcija obično trebaju imati barem jedan glagol i trebalo bi odmah biti očito što funkcija radi samo iz svog imena, ali izbjegavajte prekomjerno spuštanje previše riječi. Isto vrijedi i za nazive razreda.

6. Čarobni brojevi

Problem
Pregledavate neki kôd koji je (nadam se) netko drugi napisao i primijetite neke tvrdo kodirane brojeve. Možda su dio if-izjave ili možda dio nekih skrivenih izračuna koji, čini se, nemaju smisla. Morate mijenjati funkciju, ali jednostavno ne možete shvatiti što znače brojevi. Cue grebanje glave.

Rješenje
Pri pisanju koda, ti tzv “čarobni brojevi” treba izbjegavati pod svaku cijenu. Tvrdi brojevi imaju smisla u trenutku kada su napisani, ali mogu brzo izgubiti svako značenje - posebno kada netko drugi pokuša održavati vaš kod.

Jedno rješenje je ostaviti komentare koji objašnjavaju broj, ali bolja opcija je pretvoriti magične brojeve u stalne varijable (za izračune) ili nabrajanje (za uvjetne iskaze i prebacivanje iskaza). Davanjem imena čarobnim brojevima, kôd postaje beskonačno čitljiviji na prvi pogled i manje je sklon buggy promjenama.

7. Duboko gniježđenje

Problem
Postoje dva glavna načina završetka s duboko ugniježđenim kodom: petlje i uvjetni iskazi. Duboko ugniježđen kôd nije uvijek loš, ali može biti problematičan jer može biti teško analizirati (posebno ako varijable nisu dobro imenovane), a čak je i teže izmijeniti..

Rješenje
Ako se nađete da pišete dvostruku, trostruku ili čak četverostruku for-petlju, tada se vaš kôd možda pokušava predaleko pružiti izvan sebe kako bi pronašao podatke. Umjesto toga, navedite način na koji se podaci trebaju zatražiti putem poziva funkcije na bilo kojem objektu ili modulu koji sadrže podatke.

S druge strane, duboko ugniježđene uvjetne izjave često su znak da pokušavate nositi previše logike u jednoj funkciji ili klasi. Zapravo, duboko gniježđenje i duge funkcije obično idu ruku pod ruku. Ako vaš kôd ima masivne izjave o prebacivanju ili ugniježđene stavke ako-tad, možda ćete umjesto toga htjeti implementirati uzorak državnog stroja ili strategije.

Duboko umetanje posebno je prevladava kod neiskusnih programera igara 5 Besplatni softveri za razvoj igara za izradu vlastitih igara 5 Besplatni alati za razvoj igara za pravljenje vlastitih igara Besplatni softver za razvoj igara odličan je način za pokretanje izrade videoigara. Sastavili smo najbolji softver za igre na tržištu. !

8. Neizrečene iznimke

Problem
Iznimke su snažne, ali ih se lako zloupotrijebe. Lijeni programeri koji pogrešno koriste izjave „catch-catch“ mogu izvesti otklanjanje pogrešaka eksponencijalno teže, ako ne i nemoguće. Na primjer, ignoriranje ili zakopanje uhvaćenih iznimki.

Rješenje
Umjesto ignoriranja ili ukopavanja uhvaćenih iznimki, barem ispisujte trag stoga iznimke, tako da uređaji za uklanjanje pogrešaka imaju što raditi. Dopuštanje da vaš program tiho propadne recept je za buduće glavobolje, zajamčeno! Također, radije hvatajte određene iznimke u odnosu na opće iznimke. Saznajte više u našem članku kako na pravi način postupati s iznimkama Kako na pravi način postupati s Java iznimkama na pravi način Kako na pravi način postupati s Java iznimkama U ovom članku ćete saznati što su iznimke Java, zašto su važne, kako koristite ih i česte pogreške koje treba izbjegavati. .

9. Duplikatni kod

Problem
Istu točnu logiku izvodite u više nepovezanih područja vašeg programa. Kasnije shvaćate da trebate izmijeniti tu logiku, ali se ne sjećajte svih mjesta na kojima ste je implementirali. Na kraju ga promijenite na samo 5 od 8 mjesta, što rezultira bučnim i nedosljednim ponašanjem.

Rješenje
Duplikatni kôd glavni je kandidat za pretvaranje u funkciju. Na primjer, recimo da razvijate aplikaciju za chat i ovo pišete:

String queryUsername = getSomeUsername (); boolean jeUserOnline = netočno; for (String username: onlineUsers) if (username.equals (queryUsername)) isUserOnline = true;  if (isUserOnline) …

Negdje drugdje u kôdu, shvatili ste da trebate isto izvršiti “je ovaj korisnik na mreži?” ček. Umjesto da kopirate petlju, možete je izvući u funkciju:

javni boolean isUserOnline (String queryUsername) for (String korisničko ime: onlineUsers) if (username.equals (queryUsername)) return true;  vratiti lažno; 

Sada bilo gdje u svom kôdu možete upotrijebiti provjeru isUserOnline (). Ako ikad trebate izmijeniti ovu logiku, možete ugađati metodu i ona će se primjenjivati ​​gdje god se zove.

10. Nedostatak komentara

Problem
Kod nigdje nema nikakvih komentara. Nema blokova dokumentacije za funkcije, nema pregleda upotrebe za klase, nema objašnjenja algoritama itd. Moglo bi se tvrditi da dobro napisan kôd ne treba komentare, ali istina je da čak i najbolje napisani kod još uvijek zahtijeva više mentalne energije za razumiju nego engleski.

Rješenje
Cilj baza podataka za jednostavno održavanje, treba biti kôd napisan dovoljno dobro da nije potreba komentara, ali ih ipak ima. A kad pišete komentare, ciljajte na komentare koji objašnjavaju zašto isječak koda postoji umjesto objašnjenja što radi. Komentari su dobri za dušu i razum. Nemojte ih zanemariti.

Kako napisati kod koji ne miriše

Koliko god se očito činilo, većina mirisa kod nastaje zbog nerazumijevanja ili zanemarivanja dobrih programskih načela i obrazaca. 10 Osnovna načela programiranja Svaki programer mora slijediti 10 osnovnih načela programiranja Svaki programer mora slijediti Uvijek napišite kod koji može zadržati svatko tko može završiti na radu na vašem softveru. U tu svrhu, evo nekoliko programskih načela koja će vam pomoći da očistite svoj čin. , Na primjer, čvrsto pridržavanje principa DRY eliminira većinu dupliciranja koda, dok ovladavanje principom jedinstvene odgovornosti čini gotovo nemogućim stvaranje monstruoznih Božijih objekata.

Također preporučujemo da pročitate naš članak o tome kako napisati čistiji kod. 10 Savjeti za pisanje čistije i bolji kod 10 Savjeti za pisanje čistije i bolji kod Pisanje čistog koda izgleda lakše nego što zapravo jest, ali prednosti su vrijedne toga. Evo kako danas možete početi pisati čistiji kod. , koji se osvrće na praktičniju stranu programiranja. Ako ne možete pročitati vlastiti kôd i razumjeti ga na prvi pogled, kako će bilo tko drugi? Čist kod je kod bez mirisa.

S čime se najviše borite kada je riječ o programiranju? Podijelite s nama dolje u komentarima ispod!

Kreditna slika: SIphotography / Depositphotos