Udělali jsme to všichni: popadli cookie, když se maminka nedívala, dala si na večeři trochu vína, nechala auto sedět na parkovišti po vypršení platnosti měřiče. Dokonce jsme obcházeli Deadmanovu křivku trochu příliš rychle. A ano, všichni jsme porušili libovolný počet základních pravidel programování, ta, s nimiž každý souhlasí, jsou špatná. A tajně se nám to líbilo.
Ukázali jsme na nos pravidlům dobrého programování, vyťukali kód, který je naprosto špatný - a žili jsme. Od programujících bohů nebyly žádné blesky. Naše pracovní plochy nevybuchly. Náš kód byl ve skutečnosti sestaven a odeslán a zákazníci vypadali dost šťastní.
Je to proto, že špatné programování není ve stejné lize jako například lízání elektrického plotu nebo tahání ocasu tygra. Většinou to funguje. Pravidly jsou častěji pokyny nebo stylistické návrhy, nikoli tvrdé a rychlé směrnice, které je třeba dodržovat, jinak bude následovat smrt kódu. Jistě, váš kód může být zesměšňován, možná i veřejně. Skutečnost, že se snažíte vymlouvat konvence, přidává trochu vzrušení k podvracení, i když nechtěně, toho, co se rovná (častěji než ne) společenským zvykům příjemného kódu.
Aby toho nebylo málo, někdy je lepší pravidla porušit. (Psst!) Kód vyjde čistší. Může to být dokonce rychlejší a jednodušší. Pravidla jsou obvykle trochu příliš široká a vychytralý programátor může vylepšit kód jejich porušením. Neříkejte to svému šéfovi, ale někdy má smysl kódovat si vlastní cestu.
Následuje seznam devíti pravidel, která někteří mohou považovat za nepopiratelná, ale mnozí z nás často porušují, a to jak s úspěchem, tak s potěšením.
Špatný návyk na programování č. 1: Kopírování
Je špatné to dělat ve škole. V práci nejsou pravidla tak jasná. Určitě existují některé bloky kódu, které by neměly být ukradeny. Pokud pochází z proprietárního kódu, neskládejte jej do zásobníku, zvláště pokud je označen zprávou o autorských právech. Napište vlastní verzi. Za to vám platí.
Složitější otázka přichází, když chce původní tvůrce sdílet. Možná je na jednom z těchto online programovacích fór. Možná je to otevřený zdrojový kód s licencí (BSD, MIT), který umožňuje zachytit funkci nebo tři. Neexistuje žádný právní důvod, který by vás zastavil. A vy jste placeni za řešení problémů, ne za nové vynalézání kola.
Výhody kopírování jsou většinou přesvědčivé a nevýhody lze s trochou opatrnosti omezit. Na kód, který získáte od renomovaného zdroje, již bylo aplikováno alespoň jedno myšlenkové kolo. Původní autor hledal řešení a něco našel. Byly zpracovány invariantní smyčky a datový tok.
Složité otázky jsou, zda existují nějaké neopodstatněné chyby nebo různé předpoklady o roli nebo podkladových datech. Možná se váš kód mísí v nulových ukazatelích, zatímco původní kód je nikdy nekontroloval. Pokud problémy vyřešíte, je to, jako by váš šéf dostal vstup od dvou programátorů. Jedná se o párové programování bez přepychových stolů.
Špatný návyk na programování č. 2: Nefunkční kód
Asi poslední desetiletí funkční paradigma stoupá. Akolyti pro sestavení vašeho programu z vnořených funkcí volají rádi citovat studie ukazující, jak je kód bezpečnější a bezchybnější než starší styl proměnných a smyček, to vše navázané na sebe jakýmkoli způsobem dělá programátora šťastným. Oddaní hovoří s horlivostí skutečných věřících, kárají nefunkční přístupy při kontrole kódu a požadavcích. S výhodami mohou mít dokonce pravdu.
Někdy ale stačí vytáhnout svitek lepicí pásky. Úžasně navržený a elegantně naplánovaný kód vyžaduje čas, nejen představit si, ale také zkonstruovat a později se orientovat. Všechny tyto vrstvy zvyšují složitost a složitost je drahá. Vývojáři krásného funkčního kódu musí plánovat dopředu a zajistit, aby všechna data byla předávána správnými cestami. Někdy je jednodušší oslovit a změnit proměnnou. Možná to vysvětlete vysvětlením. Dokonce i přidání dlouhé, plazivé omluvy budoucím generacím v komentáři je rychlejší než přepracování celého systému, aby to bylo správné.
Špatný programovací zvyk č. 3: Nestandardní řádkování
Většina mezer v softwaru nemá vliv na výkon programu. Kromě několika jazyků, jako je Python, které používají mezery k označení bloků kódu, má většina mezer nulový vliv na to, jak se program chová. Přesto existují obsedantní programátoři, kteří je počítají a trvají na tom, aby na nich záleželo. Jeden z nich jednou řekl mému šéfovi nejzávažnějším tónem, že píšu „Nestandardní kód“, a on to okamžitě viděl. Můj hřích? Porušení pravidla ESLint space-infix-ops tím, že nedáte mezeru na obě strany stejného znaménka.
Někdy musíte přemýšlet o něčem hlubším, než je umístění mezer. Možná si děláte starosti s přetížením databáze. Možná se obáváte, že by váš kód mohl poškodit nulový ukazatel. Do značné míry je jakákoli část kódu důležitější než mezery, i když výbory panovačných norem s nosem neb mají plné stránky pravidel o umístění těchto mezer nebo karet.
Úžasné je, že existuje několik dobrých nástrojů, které automaticky přeformátují váš kód tak, aby dodržoval všechna přesně definovaná pravidla lintingu. Lidé o tom nemusí trávit čas přemýšlením. Pokud je to tak důležité, mohou jej spustit pomocí nástroje k odstranění problému.
Špatný programovací zvyk č. 4: Používání jít do
Zákaz používání jít do pochází z doby, kdy ještě existovalo mnoho nástrojů strukturovaného programování. Pokud by programátoři chtěli vytvořit smyčku nebo přejít na jinou rutinu, museli by psát JÍT DO následuje číslo řádku. Po několika letech týmy překladačů umožnily programátorům použít místo čísla řádku popisek řetězce. Tehdy to bylo považováno za horkou novou funkci.
Někteří označili výsledek za „špagetový kód“. Bylo nemožné, aby kdokoli přečetl váš kód později a sledoval cestu provedení. Byla to hromada vláken, navždy zamotaná. Edsger Dijkstra zakázal příkaz rukopisem s názvem „Goto Statement Považováno za škodlivé“.
Ale absolutní větvení není problém. Výsledkem je spleť. Často rafinovaný přestávka nebo vrátit se nabídne velmi čisté prohlášení o tom, co kód v daném místě dělá. Někdy přidávání jít do příkaz case vyprodukuje něco, čemu je srozumitelnější, než lépe strukturovaný seznam kaskádových bloků if-then-else.
Existují protiklady. Bezpečnostní díra „goto fail“ v zásobníku SSL společnosti Apple je jednou z nejlepších instancí. Pokud si ale dáme pozor, abychom se vyhnuli některým drsným problémům výroků případů a smyček, můžeme vložit dobré, absolutní skoky, které čtenáři usnadní pochopení toho, o co jde. Můžeme dát a přestávka nebo a vrátit se to je čistší a příjemnější pro všechny - kromě snad jít do nenávistníci.
Špatný návyk na programování č. 5: Nedeklarování typů
Lidé, kteří milují psané jazyky, mají pravdu. Píšeme lepší a bezchybnější kód, když přidáme jasná prohlášení o datovém typu každé proměnné. Pauza na chvíli, aby se vysvětlil typ, pomůže kompilátoru označit hloupé chyby před spuštěním kódu. Může to být bolest, ale pomáhá to. Jedná se o přístup k programování, který zastavuje chyby.
Časy se změnily. Mnoho z novějších kompilátorů je dostatečně chytrých, aby odvodilo typ při pohledu na kód. Mohou pracovat dopředu a dozadu prostřednictvím kódu, dokud si nebudou jisti, že proměnná musí být a tětiva nebo int nebo něco jiného. A pokud se tyto odvozené typy neshodují, kompilátoři mohou vyvolat příznak chyby. Už nepotřebují, abychom proměnné zadávali.
To znamená, že je nyní snazší ušetřit pár bitů vynecháním některých nejjednodušších deklarací. Kód se stává trochu čistší a čtenář je obvykle docela schopný uhodnout, že proměnná byla pojmenována i ve smyčce for je celé číslo.
Špatný návyk na programování č. 6: Jo-jo kód
Programátoři to rádi nazývají „jo-jo kód“. Nejprve jsou hodnoty uloženy jako řetězce. Pak jsou analyzovány na celá čísla. Pak jsou převedeny zpět na řetězce. Je to strašně neefektivní. Téměř cítíte boj CPU pod veškerým dalším zatížením. Inteligentní programátoři, kteří píší rychlý kód, navrhují své architektury tak, aby minimalizovali převody. Jejich kód běží rychleji kvůli jejich plánování.
Ale věřte tomu nebo ne, někdy to dává smysl. Někdy máte knihovnu whiz-bang, která dělá bazilión inteligentních věcí uvnitř své vlastní černé skříňky. Někdy šéf napsal sedmimístný šek, aby licencoval veškerého génia uvnitř té černé skříňky. Pokud knihovna chce data v řetězcích, dáte je knihovně v řetězcích, i když jste je nedávno převedli na celá čísla.
Jistě, můžete přepsat celý svůj kód, abyste minimalizovali převod, ale to by nějakou dobu trvalo. Někdy je v pořádku, aby kód běžel minutu, hodinu, den nebo dokonce týden navíc, protože přepsání kódu by trvalo ještě déle. Někdy je vyčerpání technického dluhu levnější než jeho vybudování.
Knihovna někdy není proprietární kód, ale kód, který jste napsali sami už dávno. Někdy je rychlejší převést data ještě jednou, než přepsat vše v této knihovně. Takže jdete dál a píšete jo-jo kód. Je to v pořádku - byli jsme tam všichni.
Špatný návyk na programování č. 7: Psaní vlastních datových struktur
Jedno ze standardních pravidel je, že programátor by nikdy neměl psát kód pro ukládání dat po absolvování kurzu datových struktur v jejich druhém ročníku. Někdo jiný již napsal všechny datové struktury, které kdy budeme potřebovat, a jejich kód byl v průběhu let testován a znovu testován. Je dodáván s jazykem a je pravděpodobně zdarma. Váš kód může obsahovat pouze chyby.
Ale někdy jsou knihovny datové struktury trochu pomalé. Někdy nás nutí do struktury, která může být pro náš kód standardní, ale špatná. Někdy nás knihovny tlačí, abychom před použitím struktury překonfigurovali naše data. Knihovny někdy obsahují ochrany pásů a podvazků s funkcemi, jako je zamykání vláken, a náš kód je nepotřebuje.
Když k tomu dojde, je čas napsat naše vlastní datové struktury. Někdy je to mnohem, mnohem rychlejší. A někdy je náš kód mnohem čistší, protože nezahrnujeme veškerý další kód pro přesné přeformátování dat.
Špatný návyk na programování č. 8: Staromódní smyčky
Kdysi dávno někdo, kdo vytvořil jazyk C, chtěl zapouzdřit všechny abstraktní možnosti do jednoho jednoduchého konstruktu. Na začátku bylo třeba udělat několik věcí, udělat něco pokaždé ve smyčce a nějaký způsob, jak zjistit, kdy je vše hotové. V té době to vypadalo jako dokonale čistá syntaxe pro zachycení nekonečných možností.
To bylo tehdy. Nyní některé moderní nadávky vidí jen potíže. Děje se příliš mnoho věcí. Všechny tyto možnosti dobra jsou také stejně špatné. O to těžší je čtení a šklebění. Milují funkčnější paradigma, kde neexistují žádné smyčky, pouze funkce aplikované na seznamy, výpočetní šablony mapované na některá data.
Jsou chvíle, kdy je loopless způsob čistší, zvláště když existuje jen jedna elegantní funkce a pole. Existují však chvíle, kdy je staromódní smyčka mnohem jednodušší, protože dokáže mnohem víc. Hledání první shody je například jednodušší, když můžete přestat, jakmile ji najdete.
Kromě toho funkce mapování podporuje nedbalejší kódování, pokud je třeba s daty provést více věcí. Představte si, že chcete vzít absolutní hodnotu a poté druhou odmocninu každého čísla. Nejrychlejším řešením je namapovat první a poté druhou funkci a dvakrát smyčkovat data.
Špatný programovací zvyk č. 9: Vylomení smyček uprostřed
Někde v řadě skupina pro tvorbu pravidel prohlásila, že každá smyčka by měla mít „invariant“, což znamená logický výrok, který je v celé smyčce pravdivý. Když invariant již není pravdivý, smyčka končí. Je to dobrý způsob, jak přemýšlet o složitých smyčkách, ale vede to k šíleným zákazům - jako je to, že nám zakazujeme používat a vrátit se nebo a přestávka uprostřed smyčky. Toto je podmnožina zakazujícího pravidla jít do prohlášení.
Tato teorie je v pořádku, ale obvykle vede ke složitějšímu kódu. Zvažte tento jednoduchý případ, který prohledá pole pro jednu položku, která projde testem:
zatímco já<>...
if (test (a [i]) then return a [i];
...
}
Milovníci invariantních smyček by raději přidali další logickou proměnnou, říkejte jí nenalezenoa použijte jej takto:
while ((notFound) && (i<>...
if (test (a [i])) then notFound = false;
...
}
Pokud je tento booleovský název dobře pojmenovaný, je to skvělý kus samodokumentujícího kódu. Může to každému usnadnit pochopení. Ale také to přidává na složitosti. A to znamená přidělit další místní proměnnou a ucpat registr, který kompilátor může nebo nemusí být dostatečně chytrý na to, aby jej opravil.
Někdy a jít do nebo je skok čistší.
Špatný návyk na programování č. 10: Předefinování operátorů a funkcí
Některé z nejzábavnějších jazyků vám umožňují dělat opravdu nevyzpytatelné věci, jako je předefinování hodnoty prvků, které vypadají, jako by měly být konstantní. Například Python vám umožňuje psát TRUE = FALSE, alespoň ve verzi 2.7 a dříve. To nevytváří nějaký druh logického kolapsu a konce vesmíru; jednoduše zamění význam SKUTEČNÝ a NEPRAVDIVÉ. Takové nebezpečné hry můžete hrát také s preprocesory C a některými dalšími jazyky. Stále jiné jazyky vám umožňují předefinovat operátory, jako je znaménko plus.
Toto je úsek, ale ve velkém bloku kódu budou body, když bude rychlejší předefinovat jednu nebo více z těchto takzvaných konstant. Někdy šéf chce, aby kód udělal něco úplně jiného. Jistě, můžete zpracovat kód a změnit každý výskyt, nebo můžete předefinovat realitu. Díky tomu můžete vypadat jako génius. Místo toho, abyste přepsali obrovskou knihovnu, jednoduše trochu otočíte a udělá to opačně.
Možná je dobré udělat tu čáru. Neměli byste to doma zkusit, bez ohledu na to, jak chytré a zábavné to může být. To je příliš nebezpečné - opravdu ... upřímné.
