Sve ozbiljne softverske firme imaju praksu code reviewa, što znači da svaki napisani kod mora proći pregled nekog drugog člana tima prije nego što uđe u pogon, tj. postane dio proizvoda. To nije testiranje, koje se obavlja prethodno, tijekom programiranja. To je doslovno čitanje koda. Čak i najboljim zaposlenicima netko drugi mora pročitati kod, iako je prethodno već testiran. Svrha je stvaranje boljeg koda, ne toliko u smislu otkrivanja bugova (iako se nađe onih koje testovi nisu uhvatili), nego uočavanje stvari koje se mogu napraviti drugačije, elegantnije, pravilnije, sigurnije, robusnije, organiziranije, čitljivije za kasnije održavanje/nadogradnju itd.

Ova praksa u natjecateljskom programiranju nije uobičajena. Ako smo riješili zadatak i prolaze svi primjeri, zašto bismo se vraćali na kod koji je ispravan? Ipak, ako je kod ispravan, ne znači nužno da je dobro napisan i da će način na koji smo ga pisali biti dobar i u budućim, težim zadatcima. Zato je korisno baciti oko i na tuđe kodove da bismo iz njih nešto naučili. No jednako je korisno da netko drugi baci oko na naš kod. Tako neki mentori, voditelji grupa ili radionica (u MIOC-u, HSIN-u, ZRS-u…) odvajaju dio svog vremena da barem površno pogledaju kodove svojih učenika i ukažu im na stvari koje se mogu bolje. Čak i za vrlo dobre natjecatelje vrijedi: kad im netko bolji/iskusniji pogleda kod, uočava stvari koje se mogu poboljšati.

Početnički primjeri uključuju:

• slabu čitljivost koda, npr. škrtarenje s razmacima i redcima (kako ćete debugirati kod koji je napisan gusto i zbrda zdola?),
• nekonzistentna ili manjkava stilska obilježja (vidi npr. ovaj post),
• nedeskriptivna imena varijabli – teško ćete se snaći u većem kodu ako vam se varijable zovu a,b,c,d,e,f,g,h,
• glomazne porcije koda (umjesto organiziranja u funkcije) i kao posljedica kod koji je teško testirati dio po dio i debugirati,
• duplikacija, tj. isti/sličan dio koda prisutan na više mjesta (lakše se griješi i teže se mijenja) umjesto izdvajanja u funkciju,
• suvišne varijable i nepotrebno kompliciranje koda (odražava neurednost misli),
• neefikasne petlje – npr. korištenje dvostruke gdje je dovoljna jedna,
• neefikasno spremanje podataka u polja/parove/strukture,
• deklaracije na lošem mjestu (uz neke iznimke, doseg varijabli treba biti najmanji mogući),
• loše organizirani slučajevi (“puno ifova”) i formule u kojima je lako pogriješiti – te stvari spominjao sam i ovdje,
• neelegantno baratanje donjim i gornjim granicama intervala (“jel tu sad ide > ili >=? plus jedan ili minus jedan?”),
• računanje istih podataka više puta, npr. unutar neke petlje, umjesto da se unaprijed izračunaju,