Vsi smo to že storili: piškotek je zaskočil, ko mama ni gledala, imel je preveč vina za večerjo, pustil je avtomobil sedeti na parkirnem mestu po izteku števca. Tudi Deadman's Curve smo šli nekoliko prehitro. In ja, vsi smo kršili katero koli glavno pravilo programiranja, za katero se vsi strinjajo, da je slaba. In nama je bilo na skrivaj všeč.
Zataknili smo se pravilom dobrega programiranja, vtipkali kodo, ki je popolnoma slaba - in živeli smo. Programskih bogov ni bilo strele. Naša namizja niso eksplodirala. Dejansko je bila naša koda sestavljena in poslana, stranke pa so se zdele dovolj srečne.
To je zato, ker slabo programiranje ni v isti ligi kot recimo lizanje električne ograje ali vlečenje repa za tigra. Največkrat se obnese. Pravila so pogosteje smernice ali slogovni predlogi, ne pa trdih in hitrih smernic, ki jih je treba upoštevati, sicer bo sledila koda smrti. Seveda bi lahko vašo kodo posmehovali, morda celo javno. Toda dejstvo, da se strinjate s konvencijami, doda malo vznemirjenja k spodkopavanju, tudi nehote, kar pomeni (najpogosteje) družbene običaje prijetne kode.
Da bi bile zadeve bolj zapletene, je včasih bolje kršiti pravila. (Pssst!) Koda je čistejša. Morda je celo hitrejši in preprostejši. Pravila so običajno nekoliko preširoka in spreten programer lahko izboljša kodo tako, da jih zlomi. Ne povejte svojemu šefu, včasih pa je smiselno kodirati po svoje.
Sledi seznam devetih pravil, ki se nekaterim zdijo neoporečna, toda mnogi od nas pogosto kršijo tako z uspehom kot z užitkom.
Slaba navada programiranja št. 1: Kopiranje
Napačno je to početi v šoli. Na delovnem mestu pravila niso tako jasna. Gotovo je nekaj blokov kode, ki jih ne bi smeli ukrasti. Če prihaja iz lastniške kode, je ne zložite v svoj kup, še posebej, če je označena s sporočilom o avtorskih pravicah. Napišite svojo različico. Za to vam plačujejo.
Bolj zapleteno vprašanje se pojavi, ko prvotni ustvarjalec želi deliti vsebino. Morda je na enem od tistih forumov za spletno programiranje. Morda gre za odprtokodno kodo z licenco (BSD, MIT), ki omogoča zapiranje funkcije ali treh. Noben pravni razlog vas ne ustavi. In plačani ste za reševanje problemov in ne za novo izumljanje kolesa.
Največkrat so prednosti kopiranja prepričljive, slabosti pa lahko z nekaj previdnosti omejimo. Koda, ki jo dobite od uglednega vira, je že imela vsaj en krog misli. Prvotni avtor je iskal rešitev in nekaj našel. Izdelani so invarianti zanke in pretok podatkov.
Težka vprašanja so, ali obstajajo neznani hrošči ali različne predpostavke o vlogi ali osnovnih podatkih. Morda se vaša koda meša v ničelne kazalce, medtem ko jih prvotna koda ni nikoli preverila. Če lahko težave odpravite, je, kot da vaš šef dobi vnos od dveh programerjev. To je programiranje v paru brez modnih miz.
Slaba navada programiranja št. 2: Nefunkcionalna koda
V zadnjem desetletju se funkcionalna paradigma vzpenja. Akoliti za gradnjo vašega programa iz ugnezdenih funkcijskih klicev radi navajajo študije, ki kažejo, kako je koda varnejša in brez napak kot starejši slog spremenljivk in zank, ki so vsi na kakršen koli način razvejani programerja. Bhakte govorijo z vnemo resničnih vernikov, pri pregledu kode in povpraševanju prosijo za nefunkcionalne pristope. Glede prednosti imajo morda celo prav.
Toda včasih morate samo izvleči zvitek lepilnega traku. Čudovito izdelana in graciozno načrtovana koda potrebuje čas, ne samo za predstavljanje, temveč tudi za konstruiranje in kasnejše krmarjenje. Vse te plasti dodajajo zapletenost in zapletenost je draga. Razvijalci čudovite funkcionalne kode morajo načrtovati vnaprej in zagotoviti, da se vsi podatki prenašajo po ustreznih poteh. Včasih je preprosto lažje doseči in spremeniti spremenljivko. Morda da komentar v obrazložitev. Tudi dodajanje dolgega, globokega opravičila prihodnjim generacijam v komentarju je hitrejše kot ponovna arhitektura celotnega sistema, da bo to storil na pravi način.
Slaba programska navada št. 3: Nestandardni razmik
Večina prostorov v programski opremi nima vpliva na delovanje programa. Razen nekaterih jezikov, kot je Python, ki uporabljajo presledke za označevanje blokov kode, večina presledkov nima ničesar vpliva na to, kako se program obnaša. Kljub temu obstajajo obsesivni programerji, ki jih štejejo in vztrajajo, da so pomembni. Eden od njih je mojemu šefu nekoč z najresnejšim tonom rekel, da pišem "Nestandardno kodo", in to je lahko takoj videl. Moj greh? Kršitev pravila ESLint space-infix-ops, ker presledek na obeh straneh enakovrednega znaka ni postavljen.
Včasih je treba preprosto pomisliti na kaj globljega kot umestitev prostorov. Morda vas skrbi, da bi se baza podatkov preobremenila. Morda vas skrbi, kako bi ničelni kazalec zrušil vašo kodo. Skoraj kateri koli del kode je pomembnejši od presledkov, četudi so nenavadni, šefovski odbori za standarde zapolnili strani pravil o postavitvi teh presledkov ali zavihkov.
Neverjetno je, da obstaja več dobrih orodij, ki samodejno preoblikujejo kodo, da se drži natančno določenih pravil povezovanja. Ljudem ni treba porabiti časa za razmišljanje o tem. Če je tako pomembno, lahko z orodjem popravijo težavo.
Slaba programska navada št. 4: Uporaba Pojdi do
Prepoved uporabe Pojdi do sega v dobo, preden so številna orodja strukturiranega programiranja sploh obstajala. Če bi programerji želeli ustvariti zanko ali preskočiti na drugo rutino, bi morali tipkati POJDI DO čemur sledi številka vrstice. Po nekaj letih prevajalniške ekipe programerjem dovolijo, da namesto številke vrstice uporabljajo oznako niza. Takrat je to veljalo za vročo novost.
Nekateri so rezultat poimenovali »špageti koda«. Nihče ni mogel pozneje prebrati vaše kode in slediti poti izvedbe. Bilo je mešanje niti, za vedno zapleteno. Edsger Dijkstra je ukaz prepovedal z rokopisom, z naslovom "Goto Statement Considered škodljiv."
A absolutna razvejanost ni težava. Rezultat je preplet. Pogosto spreten odmor ali vrnitev bo ponudil zelo čisto izjavo o tem, kaj koda počne na tej lokaciji. Včasih dodajanje Pojdi do za stavek primera ustvari nekaj, kar je enostavneje razumeti kot bolj pravilno strukturiran seznam kaskadnih blokov if-then-else.
Obstajajo nasprotni primeri. Varnostna luknja »goto fail« v Appleovem SSL-jevem skladu je eden najboljših primerov. Če pa se pazimo, da se izognemo nekaterim okornim vprašanjem izjav in zank, lahko vstavimo dobre, absolutne skoke, ki bralcu olajšajo razumevanje dogajanja. Vstavimo lahko odmor ali a vrnitev ki je čistejši in bolj prijeten za vse - razen morda za Pojdi do sovražniki.
Slaba programska navada št. 5: Nerazglasitev tipov
Ljudje, ki imajo radi tipkarske jezike, imajo svoje mnenje. Ko dodamo jasne izjave o podatkovnem tipu vsake spremenljivke, pišemo boljšo kodo brez napak. Zastajanje trenutka za črkovanje tipa pomaga prevajalniku zastaviti neumne napake, preden se koda začne izvajati. Mogoče je bolečina, vendar pomaga. Gre za pristop pasov in naramnic pri programiranju, ki ustavi napake.
Časi so se spremenili. Mnogi novejši prevajalniki so dovolj pametni, da lahko s pomočjo kode sklepajo na tip. Skozi kodo lahko delujejo naprej in nazaj, dokler niso prepričani, da mora biti spremenljivka a vrvica ali an int ali kaj drugega. In če se ti izpeljani tipi ne ujemajo, lahko prevajalniki dvignejo zastavico napake. Ne potrebujemo več, da spremenljivk vnašamo.
To pomeni, da je zdaj lažje prihraniti nekaj bitov, tako da izpustite nekatere najpreprostejše izjave. Koda postane nekoliko čistejša in bralec običajno lahko ugane, da je imenovana spremenljivka jaz v zanki for je celo število.
Slaba programska navada št. 6: Yo-yo koda
Programerji ji radi rečejo »yo-yo koda«. Najprej se vrednosti shranijo kot nizi. Potem se razčlenijo na cela števila. Potem se pretvorijo v nize. To je strašno neučinkovito. Skoraj lahko začutite, kako se CPU bori pri vseh dodatnih obremenitvah. Pametni programerji, ki pišejo hitro kodo, oblikujejo svoje arhitekture, da zmanjšajo število konverzij. Njihova koda teče hitreje zaradi njihovega načrtovanja.
Toda verjeli ali ne, včasih je to smiselno. Včasih imate knjižnico whiz-bang, ki v svoji zaščiteni črni škatli naredi milijon inteligentnih stvari. Včasih je šef napisal sedemmestni ček, s katerim je licenciral vsega genija znotraj črne škatle. Če knjižnica želi podatke v nizih, jih daste knjižnici v nizih, tudi če ste jih nedavno pretvorili v cela števila.
Seveda lahko celotno kodo prepišete, da minimizirate pretvorbo, vendar bi to zahtevalo čas. Včasih je v redu, da koda zažene dodatno minuto, uro, dan ali celo teden, ker bi prepis kode trajal še več časa. Včasih je zmanjšanje tehničnega dolga cenejše, kot da bi ga sploh ustvarili.
Včasih knjižnica ni lastniška koda, ampak koda, ki ste jo že sami napisali. Včasih je podatke hitreje pretvoriti še enkrat, kot pa prepisati vse v tej knjižnici. Torej greš zraven in napišeš yo-yo kodo. V redu je - vsi smo že bili tam.
Slaba navada pri programiranju št. 7: Pisanje lastnih podatkovnih struktur
Eno od standardnih pravil je, da programer nikoli ne napiše kode za shranjevanje podatkov po končanem tečaju podatkovnih struktur v drugem letu. Nekdo drug je že napisal vse podatkovne strukture, ki jih bomo kdaj potrebovali, njegova koda pa je bila z leti preizkušena in preizkušena. Vključen je v jezik in je verjetno brezplačen. Vaša koda lahko vsebuje samo napake.
Toda včasih so knjižnice podatkovne strukture nekoliko počasne. Včasih nas prisilijo v strukturo, ki je lahko standardna, a napačna za našo kodo. Včasih nas knjižnice potisnejo k ponovni konfiguraciji podatkov, preden uporabimo strukturo. Včasih knjižnice vključujejo zaščito pasov in naramnic s funkcijami, kot je zaklepanje niti, in jih naša koda ne potrebuje.
Ko se to zgodi, je čas, da napišemo lastne podatkovne strukture. Včasih je veliko, veliko hitreje. Včasih je naša koda bistveno bolj čista, ker ne vključujemo vse dodatne kode za preoblikovanje podatkov točno tako.
Slaba navada programiranja št. 8: Staromodne zanke
Že zdavnaj je nekdo, ki je ustvaril jezik C, želel povzeti vse abstraktne možnosti v en preprost konstrukt. Nekaj stvari je bilo treba narediti na začetku, nekaj stvari, ki jih je treba opraviti vsakič skozi zanko, in nekaj načinov, kako ugotoviti, kdaj je bilo vse narejeno. Takrat se je zdela popolnoma čista sintaksa za zajemanje neskončnih možnosti.
To je bilo takrat. Zdaj nekateri sodobni graji vidijo samo težave. Preveč stvari se dogaja. Vse te možnosti za dobroto so enako sposobne tudi za slabo. Branje in grokanje je toliko težje. Všeč jim je bolj funkcionalna paradigma, kjer ni zank, samo funkcije, ki se uporabljajo za sezname, računske predloge, preslikane v nekatere podatke.
Včasih je način brez ljudi čistejši, še posebej, če obstaja samo ena urejena funkcija in matrika. Toda včasih je staromodna zanka veliko preprostejša, saj lahko naredi veliko več. Iskanje prve tekme je na primer preprostejše, ko se lahko ustavite takoj, ko jo najdete.
Poleg tega funkcije preslikave spodbujajo bolj zapleteno kodiranje, kadar je za podatke treba narediti več stvari. Predstavljajte si, da želite vzeti absolutno vrednost in nato kvadratni koren vsakega števila. Najhitrejša rešitev je preslikava prve funkcije in nato druge, ki dvakrat pregleduje podatke.
Slaba programska navada št. 9: Prekinitev zank na sredini
Nekje po črti je skupina za oblikovanje pravil razglasila, da mora imeti vsaka zanka "nespremenljivko", kar pomeni, da je logična izjava resnična v celotni zanki. Ko invariant ni več resničen, se zanka konča. To je dober način za razmišljanje o zapletenih zankah, vendar vodi do norih prepovedi - na primer prepovedi uporabe a vrnitev ali a odmor na sredini zanke. To je podskupina pravila, ki prepoveduje Pojdi do izjave.
Ta teorija je v redu, vendar običajno vodi do bolj zapletene kode. Razmislite o tem preprostem primeru, ki skenira matriko za en vnos, ki opravi test:
medtem ko jaz<>...
if (test (a [i]), nato vrnite a [i];
...
}
Ljubitelji invariantov zanke bi raje dodali še eno logično spremenljivko, jo pokličite ni najdeno, in ga uporabite tako:
while ((notFound) && (i<>...
if (test (a [i])) then notFound = false;
...
}
Če je ta logična vrednost dobro poimenovana, je to odlična samokopirna koda. Morda bo vsem olajšano razumevanje. Je pa tudi dodana zapletenost. To pomeni dodelitev druge lokalne spremenljivke in zamašitev registra, ki ga je prevajalnik morda dovolj pameten, da ga popravi.
Včasih a Pojdi do ali pa je skok čistejši.
Slaba programska navada št. 10: Ponovna opredelitev operaterjev in funkcij
Nekateri najbolj zabavni jeziki vam omogočajo, da počnete resnično zanične stvari, na primer redefiniranje vrednosti elementov, za katere je videti, da bi morali biti stalni. Python vam na primer omogoča tipkanje TRUE = FALSE, vsaj v različici 2.7 in prej. To ne ustvari neke vrste logičnega kolapsa in konca vesolja; preprosto zamenja pomen PRAV in NAPAKA. Takšne nevarne igre lahko igrate tudi s predprocesorji C in nekaterimi drugimi jeziki. Spet drugi jeziki vam omogočajo, da na novo definirate operatorje, kot je znak plus.
To je raztezanje, vendar bodo v velikem bloku kode točke, ko bo hitreje na novo definirati eno ali več teh tako imenovanih konstant. Včasih šef želi, da bi koda naredila nekaj povsem drugega. Seveda bi lahko obdelali kodo in spremenili vsak pojav ali pa na novo definirali resničnost. Videti si lahko kot genij. Namesto da napišete ogromno knjižnico, preprosto malo prelistate in stori ravno obratno.
Morda je dobro tu potegniti črto. Tega ne smete preizkušati doma, ne glede na to, kako pametno in zabavno je lahko. To je preveč nevarno - res ... iskreno.
