Urobili sme to všetci: zachytili sme cookie, keď sa mama nepozerala, dala si na večeru príliš veľa vína a po uplynutí počítadla nechajte auto sedieť na parkovisku. Dokonca sme obehli Deadmanovu krivku trochu príliš rýchlo. A áno, všetci sme porušili akýkoľvek počet základných pravidiel programovania, tie, s ktorými každý súhlasí, sú zlé. A tajne sa nám to páčilo.
Švihli sme nosom nad pravidlami dobrého programovania, vybrali sme kód, ktorý je úplne zlý - a žili sme. Z programátorských bohov nezasahovali žiadne blesky. Naše pracovné plochy nevybuchli. V skutočnosti sa náš kód skompiloval a odoslal a zákazníci sa zdali dosť spokojní.
Je to preto, lebo zlé programovanie nie je v tej istej lige ako napríklad lízanie elektrického plotu alebo ťahanie za chvost tigra. Väčšinou to vyjde. Pravidlami sú častejšie pokyny alebo štylistické návrhy, nie tvrdé a rýchle smernice, ktoré sa musia dodržiavať, inak bude nasledovať smrť smrti. Iste, vášmu kódu sa možno vysmievajú, dokonca aj verejne. Skutočnosť, že vymýšľate konvencie, však trochu vzrušuje tým, že podvracia, aj keď nechtiac, to, čo predstavuje (viac často ako iné) spoločenské mravy príjemného kódu.
Aby to nebolo tak jednoduché, niekedy je lepšie porušovať pravidlá. (Psst!) Kód vyjde čistejší. Môže to byť dokonca rýchlejšie a jednoduchšie. Pravidlá sú zvyčajne trochu príliš široké a zručný programátor môže vylepšiť kód ich porušením. Nehovorte to svojmu šéfovi, ale niekedy má zmysel kódovať si svoj vlastný spôsob.
Nasleduje zoznam deviatich pravidiel, ktoré niektorí môžu považovať za nepopierateľné, ale mnohí z nás často porušujú pravidlá úspechu i potešenia.
Zlý programovací zvyk č. 1: Kopírovanie
Je nesprávne robiť to v škole. V práci nie sú pravidlá také jasné. Určite existujú niektoré bloky kódu, ktoré by nemali byť ukradnuté. Ak pochádza z vlastného kódu, neskládajte ho do balíka, najmä ak je označený správou o autorských právach. Napíšte svoju vlastnú verziu. Za to vám platia.
Zložitejšia otázka prichádza, keď sa chce pôvodný tvorca podeliť. Možno je na jednom z týchto fór online programovania. Možno je to otvorený zdrojový kód s licenciou (BSD, MIT), ktorá umožňuje zachytenie funkcie alebo troch. Neexistuje žiadny právny dôvod, ktorý by vás zastavil. A ste platení za to, aby ste vyriešili problémy, nie aby ste znova objavili koleso.
Výhody kopírovania sú väčšinou presvedčivé a nevýhody je možné pri troche starostlivosti obmedziť. Na kód, ktorý získate od renomovaného zdroja, už bolo aplikované minimálne jedno myšlienkové riešenie. Pôvodný autor hľadal riešenie a niečo našiel. Smyčkové invarianty a dátový tok boli vypracované.
Zložité otázky sú, či existujú nejaké neopodstatnené chyby alebo odlišné predpoklady o úlohe alebo základných údajoch. Možno sa váš kód zmieša v nulových ukazovateľoch, zatiaľ čo pôvodný kód ich nikdy nekontroloval. Ak môžete problém vyriešiť, je to, akoby váš šéf získaval vstup od dvoch programátorov. Je to párové programovanie bez efektných stolov.
Zlý programovací zvyk č. 2: Nefunkčný kód
Asi posledné desaťročie funkčná paradigma stúpa. Akolyti, ktorí zostavujú váš program z vnorenej funkcie, volajú rád citovať štúdie, ktoré ukazujú, ako je kód bezpečnejší a bez chýb ako starší štýl premenných a cyklov, ktoré sú navzájom spojené akýmkoľvek spôsobom, čo robí programátora šťastným. Oddaní hovoria s horlivosťou skutočných veriacich a kárajú nefunkčné prístupy pri kontrole kódu a požiadavkách. S výhodami môžu mať dokonca pravdu.
Niekedy však stačí vytiahnuť zvitok lepiacej pásky. Úžasne navrhnutý a elegantne naplánovaný kód si vyžaduje čas, nielen predstavenie, ale aj zostrojenie a neskôr navigácia. Všetky tieto vrstvy zvyšujú zložitosť a sú zložité. Vývojári nádherného funkčného kódu musia plánovať vopred a zabezpečiť, aby boli všetky údaje odovzdávané správnymi cestami. Niekedy je jednoduchšie osloviť a zmeniť premennú. Možno vložím komentár, ktorý to vysvetlí. Aj pridanie dlhého, plazivého ospravedlnenia budúcim generáciám do komentára je rýchlejšie ako opätovné zostavenie celého systému, aby to urobil správnym spôsobom.
Zlý programovací zvyk č. 3: Neštandardné medzery
Väčšina priestorov v softvéri nemá vplyv na výkonnosť programu. Okrem niekoľkých jazykov ako Python, ktoré používajú medzery na označenie blokov kódu, má väčšina medzier nulový vplyv na to, ako sa program správa. Stále existujú obsedantní programátori, ktorí ich počítajú a trvajú na tom, aby na nich záležalo. Jeden z nich raz povedal svojmu šéfovi tým najvážnejším tónom, že píšem „Neštandardný kódex“, a on to okamžite videl. Môj hriech? Porušenie pravidla ESLint space-infix-ops tým, že sa na obidve strany neoznačuje rovnaké znamienko.
Niekedy musíte myslieť len na niečo hlbšie, ako je rozmiestnenie priestorov. Možno sa obávate preťaženia databázy. Možno sa obávate, že by váš kód mohol zlyhať nulový ukazovateľ. V skutočnosti je ktorákoľvek časť kódu dôležitejšia ako medzery, aj keď výbory pre šéfovské štandardy s nebeským nosom vyplnili stránky pravidiel o umiestnení týchto medzier alebo tabulátorov.
Úžasné je, že existuje niekoľko dobrých nástrojov, ktoré automaticky preformátujú váš kód tak, aby vyhovoval všetkým presne stanoveným pravidlám usporiadania. Ľudia nemusia tráviť čas premýšľaním o tom. Ak je to také dôležité, môžu to spustiť prostredníctvom nástroja na odstránenie problému.
Zlý programovací zvyk č. 4: Používanie ísť do
Zákaz používania ísť do datuje do éry predtým, ako mnohé z nástrojov štruktúrovaného programovania vôbec existovali. Ak by programátori chceli vytvoriť slučku alebo prejsť na inú rutinu, bolo by potrebné zadať text ÍSŤ DO za ktorým nasleduje číslo riadku. Po niekoľkých rokoch tímy kompilátorov umožnili programátorom použiť namiesto čísla riadku štítok reťazca. To sa v tom čase považovalo za horúcu novú funkciu.
Niektorí výsledok nazvali „špagetový kód“. Bolo nemožné, aby si ktokoľvek prečítal váš kód neskôr a nasledoval cestu vykonania. Bola to hromada vlákien, navždy zamotaná. Edsger Dijkstra zakázal príkaz pomocou rukopisu s názvom „Goto vyhlásenie považované za škodlivé“.
Ale absolútne rozvetvenie nie je problém. Výsledkom je spleť. Často rafinované prestávka alebo návrat ponúkne veľmi čisté vyhlásenie o tom, čo kód na danom mieste robí. Niekedy pridanie ísť do výrok prípadu vyprodukuje niečo, čomu sa dá ľahšie porozumieť, ako vhodnejšie štruktúrovaný zoznam kaskádových blokov if-then-else.
Existujú protiklady. Diera zabezpečenia „choď zlyhať“ v zásobníku SSL spoločnosti Apple je jedným z najlepších prípadov. Ak však dáme pozor, aby sme sa vyhli niektorým drsným problémom výrokov a cyklov prípadov, môžeme vložiť dobré, absolútne skoky, ktoré čitateľovi uľahčia pochopenie toho, o čo ide. Môžeme vložiť a prestávka alebo a návrat to je čistejšie a príjemnejšie pre všetkých - okrem snáď ísť do neprajníci.
Zlý programovací zvyk č. 5: Nedeklarovanie typov
Ľudia, ktorí milujú písané jazyky, majú pravdu. Píšeme lepší a bezchybnejší kód, keď k každej premennej pridáme jasné deklarácie o dátovom type. Pozastavenie chvíľky na vysvetlenie typu pomáha kompilátorovi označiť hlúpe chyby skôr, ako sa začne kód spúšťať. Môže to byť bolesť, ale pomáha to. Je to prístup opaskov a podväzkov k programovaniu, ktorý zastaví chyby.
Časy sa zmenili. Mnoho z novších prekladačov je dosť inteligentných na to, aby odvodili typ pri pohľade na kód. Môžu pracovať dopredu a dozadu cez kód, kým si nebudú istí, že premenná musí byť a struna alebo an int alebo niečo iné. A ak sa tieto odvodené typy nezhodujú, môže kompilátor zvýšiť príznak chyby. Už viac nepotrebujú, aby sme premenné zadávali.
To znamená, že je teraz jednoduchšie ušetriť pár bitov vynechaním najjednoduchších vyhlásení. Kód sa stáva trochu čistejším a čitateľ je zvyčajne celkom schopný uhádnuť, že premenná bola pomenovaná i v cykle for je celé číslo.
Zlý programovací zvyk č. 6: Jo-jo kód
Programátori to radi nazývajú „jo-jo kód“. Najskôr sa hodnoty uložia ako reťazce. Potom sa rozdelia na celé čísla. Potom sa prevedú späť na reťazce. Je to strašne neefektívne. Pri všetkej dodatočnej záťaži takmer cítite boj CPU. Inteligentní programátori, ktorí píšu rýchly kód, navrhujú svoje architektúry tak, aby minimalizovali konverzie. Ich kód beží rýchlejšie z dôvodu ich plánovania.
Ale verte tomu alebo nie, niekedy to má zmysel. Niekedy máte knižnicu svišťania, ktorá vo vlastnej čiernej skrinke robí bazilión inteligentných vecí. Šéf niekedy napísal sedemmiestny šek, aby získal licenciu na všetkých geniálnych ľudí v tej čiernej skrinke. Ak knižnica chce údaje v reťazcoch, dáte ich knižnici v reťazcoch, aj keď ste ich nedávno previedli na celé čísla.
Iste, celý svoj kód môžete prepísať, aby ste minimalizovali konverziu, ale chce to čas. Niekedy je dobré, aby kód bežal o minútu, hodinu, deň alebo dokonca týždeň navyše, pretože prepisovanie kódu by trvalo ešte viac času. Niekedy je vyčerpanie technického dlhu lacnejšie ako jeho vybudovanie.
Knižnica niekedy nie je vlastný kód, ale kód, ktorý ste si napísali už dávno. Niekedy je rýchlejšie previesť údaje ešte raz, ako prepísať všetko v tejto knižnici. Takže pôjdete ďalej a napíšete jo-jo kód. Je to v poriadku - všetci sme tam boli.
Zlý programovací zvyk č. 7: Písanie vlastných dátových štruktúr
Jedným zo štandardných pravidiel je, že programátor by nikdy nemal písať kód na ukladanie údajov po absolvovaní kurzu dátových štruktúr v druhom ročníku. Niekto iný už napísal všetky dátové štruktúry, ktoré kedy budeme potrebovať, a ich kód bol rokmi testovaný a testovaný. Je dodávaný s jazykom a je pravdepodobne zadarmo. Váš kód môže obsahovať iba chyby.
Ale niekedy sú knižnice dátových štruktúr trochu pomalé. Niekedy nás nútia do štruktúry, ktorá môže byť pre náš kód štandardná, ale nesprávna. Knižnice nás niekedy tlačia do prekonfigurovania našich údajov skôr, ako použijeme štruktúru. Knižnice niekedy obsahujú ochrany pásov a podväzkov s funkciami, ako je uzamykanie závitov, a náš kód ich nepotrebuje.
Keď sa to stane, je čas napísať naše vlastné dátové štruktúry. Niekedy je to oveľa, oveľa rýchlejšie. A niekedy to robí náš kód oveľa čistejším, pretože nezahŕňame celý ďalší kód na presné preformátovanie údajov.
Zlý programovací zvyk č. 8: Staromódne slučky
Dávno chcel niekto, kto vytvoril jazyk C, zapuzdriť všetky abstraktné možnosti do jedného jednoduchého konštruktu. Na začiatku bolo treba urobiť niečo, urobiť zakaždým opakovaním a urobiť nejaký spôsob, ako zistiť, kedy je všetko hotové. V tom čase to vyzeralo ako úplne čistá syntax na zachytenie nekonečných možností.
To bolo vtedy. Teraz niektoré moderné nadávky vidia iba problémy. Veci sa dejú príliš veľa. Všetky tieto možnosti dobra sú rovnako schopné aj zlého. Oveľa ťažšie to robí čítanie a grokovanie. Páči sa im funkčnejšia paradigma, v ktorej neexistujú žiadne slučky, iba funkcie aplikované na zoznamy, výpočtové šablóny namapované na niektoré údaje.
Sú chvíle, kedy je bezšvová cesta čistejšia, najmä keď existuje iba jedna elegantná funkcia a pole. Ale sú chvíle, keď je staromódna slučka oveľa jednoduchšia, pretože dokáže oveľa viac. Napríklad hľadanie prvej zhody je jednoduchšie, keď môžete zastaviť ihneď po ich nájdení.
Okrem toho mapovacie funkcie podporujú nedbanlivejšie kódovanie, keď je s údajmi potrebné urobiť viac vecí. Predstavte si, že chcete brať absolútnu hodnotu a potom druhú odmocninu každého čísla. Najrýchlejším riešením je namapovať prvú a potom druhú funkciu a dáta slučkovať dvakrát.
Zlý programovací zvyk č. 9: Vytrhnutie zo slučiek v strede
Skupina pre tvorbu pravidiel niekde v tomto smere deklarovala, že každá slučka by mala mať „invariant“, čo znamená logické tvrdenie, ktoré platí v celej slučke. Keď invariant už neplatí, slučka sa končí. Je to dobrý spôsob, ako premýšľať o zložitých slučkách, ale vedie to k šialeným zákazom - napríklad k zákazu používať a návrat alebo a prestávka v strede slučky. Toto je podmnožina pravidla zakazujúceho ísť do Vyhlásenia.
Táto teória je v poriadku, ale zvyčajne vedie k zložitejšiemu kódu. Zvážte tento jednoduchý prípad, ktorý prehľadá pole pre jednu položku, ktorá prejde testom:
kým<>...
if (test (a [i]) then return a [i];
...
}
Milovníci invariantných slučiek by radšej pridali ďalšiu boolovskú premennú, nazvime ju nenájdené, a použite ho takto:
while ((nenájdené) && (i<>...
if (test (a [i])) then notFound = false;
...
}
Ak má tento booleov dobrý názov, je to vynikajúci kus samodokumentujúceho kódu. Môže to každému uľahčiť porozumenie. Ale tiež to zvyšuje zložitosť. A to znamená prideliť ďalšiu lokálnu premennú a upchať register, ktorý kompilátor môže alebo nemusí byť natoľko inteligentný, aby ho napravil.
Niekedy a ísť do alebo je skok čistejší.
Zlý programovací zvyk č. 10: Predefinovanie operátorov a funkcií
Niektoré z najzábavnejších jazykov vám umožňujú robiť skutočne zákerné veci, ako je predefinovanie hodnoty prvkov, ktoré vyzerajú, akoby mali byť stále. Napríklad Python vám umožňuje písať PRAVDA = NEPRAVDA, minimálne vo verzii 2.7 a predchádzajúcej verzii. Toto nevytvára nejaký druh logického kolapsu a konca vesmíru; jednoducho zamení význam PRAVDA a NEPRAVDA. Takéto nebezpečné hry môžete hrať aj s preprocesormi C a niektorými ďalšími jazykmi. Stále ďalšie jazyky vám umožňujú predefinovať operátory ako znamienko plus.
Toto je úsek, ale vo veľkom bloku kódu budú body, keď bude rýchlejšie predefinovať jednu alebo viac z týchto takzvaných konštánt. Niekedy šéf chce, aby kód urobil niečo úplne iné. Iste, môžete prepracovať kód a zmeniť každý výskyt, alebo môžete predefinovať realitu. Môže to spôsobiť, že budete vyzerať ako génius. Namiesto prepisovania obrovskej knižnice jednoducho trochu otočíte a je to naopak.
Možno je dobré urobiť tu čiaru. Toto by ste doma nemali skúšať, nech už to je akokoľvek chytré a zábavné. To je príliš nebezpečné - naozaj ... úprimné.
