Váš kód může cítit! Jak to opravit

A vůně kódu je kus kódu nebo obecný kódovací vzorec, který vypadá, že by mohl naznačovat hlubší problém v celkové struktuře a designu codebase.

Představte si vůni kódu jako jakékoli znamení, které naznačuje, že část kódu by měla být znovu upravena. Nejde o to, že kód je buggy nebo nefunkční - často se smradlavý kód spouští dobře - ale smradlavý kód je často obtížné udržovat a rozšiřovat, což může vést k technickým problémům (zejména u větších projektů).

V tomto článku vyzdvihneme 10 nejčastějších pachů kódu, co hledat a jak je deodorizovat. Pokud jste nový programátor Jak se učit programování bez stresu Jak se učit programování bez stresu Možná jste se rozhodli programovat, ať už pro kariéru nebo jen jako koníček. Skvělý! Ale možná se začínáte cítit ohromeni. Není to tak skvělé. Zde je nápověda, která vám usnadní cestu. , vyhněte se jim a váš kód bude znatelně lepší!

1. Těsné spojení

Problém
Těsné spojení je, když dva objekty jsou tak závislé na sobě navzájem na datech a / nebo funkcích, které modifikace jednoho vyžaduje úpravu druhého. Pokud jsou dva objekty spojeny příliš těsně, může být změna kódu noční můrou a je pravděpodobnější, že při každé změně zavedete chyby..

Například:

třída Worker Bike bike = new Bike (); public void commute () bike.drive (); 

V tomto případě jsou Worker a Bike pevně spojeny. Co když jednoho dne chcete pro dojíždění řídit auto místo kola? Museli byste jít do třídy Worker a nahradit veškerý kód související s Bike kódem souvisejícím s Car. Je to chaotický a náchylný k chybám.

Řešení
Spojení můžete uvolnit přidáním vrstvy abstrakce. V tomto případě třída Worker nechce řídit pouze kola, ale také auta, možná i kamiony, možná i skútry. To jsou všechna vozidla, že? Vytvořte tedy rozhraní vozidla, které vám umožní podle potřeby vkládat a vyměňovat různé typy vozidel:

třída pracovník vozidlo vozidla; public void changeVehicle (Vehicle v) vehicle = v;  public void commute () vehicle.drive ();  rozhraní Vozidlo void drive ();  třída Bike implementuje vozidlo public void drive ()  třída car implementuje vozidlo public void drive () 

2. Bůh objekty

Problém
Boží objekt je masivní třída / modul, který obsahuje příliš mnoho proměnných a funkcí. To “ví příliš mnoho” a “dělá moc,” což je problematické ze dvou důvodů. Za prvé, jiné třídy / moduly se na tuto třídu příliš spoléhají, pokud jde o data (pevné spojení). Za druhé, celková struktura programu se stává blátivou, když je vše nacpané na stejné místo.

Řešení
Vezměte božský objekt, oddělte jeho data a funkce podle toho, jaké problémy existují, aby je vyřešily, a pak tyto seskupení změňte na objekty. Pokud máte Boží objekt, může to být lepší jako složení mnoha menších objektů.

Předpokládejme například, že máte monstrózní třídu User:

class User public String username; veřejné řetězcové heslo; veřejná řetězcová adresa; public String zipcode; public int age;… public String getUsername () návrat username;  public void setUsername (String u) username = u; 

Dalo by se převést na složení následující:

class User Pověření pověření; Profil profilu;… třída Credentials public String username; public String password;… public String getUsername () návrat username;  public void setUsername (String u) username = u; 

Až budete příště muset upravit přihlašovací postupy, nemusíte procházet masivní třídu uživatelů, protože třída Credentials je lépe zvládnutelná!

3. Dlouhé funkce

Problém
Dlouhá funkce je přesně to, co zní: funkce, která se rozrostla příliš dlouho. I když neexistuje konkrétní číslo pro kolik řádků kódu je “příliš dlouho” pro nějakou funkci je to jedna z věcí, kde ji znáte, když ji uvidíte. Je to skoro užší verze problému s objektem Boha - dlouhá funkce má příliš mnoho povinností.

Řešení
Dlouhé funkce by měly být rozděleny do mnoha dílčích funkcí, kde každá dílčí funkce je navržena tak, aby zvládla jeden úkol nebo problém. V ideálním případě se původní dlouhá funkce změní na seznam dílčích volání, díky čemuž je kód čistší a snáze čitelný.

4. Nadměrné parametry

Problém
Funkce (konstruktor třídy), která vyžaduje příliš mnoho parametrů, je problematická ze dvou důvodů. Zaprvé, kód je méně čitelný a je obtížnější testovat. Za druhé, a co je důležitější, může to naznačovat, že účel funkce je příliš nejednoznačný a snaží se zvládnout příliš mnoho povinností.

Řešení
Zatímco “příliš mnoho” je subjektivní pro seznam parametrů, doporučujeme si dát pozor na každou funkci, která má více než 3 parametry. Jistě, někdy má smysl mít jednu funkci s 5 nebo dokonce 6 parametry, ale pouze v případě, že pro to existuje opravdu dobrý důvod.

Většinu času neexistuje a kód by byl lepší rozdělit tuto funkci na dvě nebo více různých funkcí. Na rozdíl od “Dlouhé funkce” kódový zápach, tento nelze vyřešit pouhým nahrazením kódu subfunkcemi - funkce samotná musí být rozdělena a rozdělena do samostatných funkcí pokrývajících samostatné odpovědnosti.

5. Špatně pojmenované identifikátory

Problém
Jedno nebo dvoupísmenné názvy proměnných. Názvy funkcí bez popisu. Příliš zdobená jména tříd. Názvy proměnných s jejich typem (např. B_isCounted pro booleovskou proměnnou). A co je nejhorší, smíchání různých schémat pojmenování v rámci jedné kódové základny. To vše vede k obtížně čitelnému, těžko srozumitelnému a obtížně udržovatelnému kódu.

Řešení
Sbírání dobrých jmen pro proměnné, funkce a třídy je těžko naučená dovednost. Pokud se připojujete k existujícímu projektu, pročtěte jej a prohlédněte si, jak jsou pojmenovány stávající identifikátory. Pokud existuje průvodce stylem, zapamatujte si jej a dodržujte ho. U nových projektů zvažte vytvoření vlastního průvodce stylem a držte se ho.

Obecně by názvy proměnných měly být krátké, ale popisné. Názvy funkcí by obvykle měly mít alespoň jedno sloveso a mělo by být okamžitě zřejmé, co funkce dělá jen ze svého názvu, ale vyvarujte se napěchování příliš mnoha slovy. Totéž platí pro názvy tříd.

6. Kouzelná čísla

Problém
Prohlížíte nějaký kód, který (doufejme) napsal někdo jiný, a všimnete si některých čísel v pevném kódu. Možná jsou součástí prohlášení if, nebo možná součástí některých tajemných výpočtů, které, jak se zdá, nedávají smysl. Musíte tuto funkci upravit, ale nemůžete pochopit, co čísla znamenají. Cue poškrábání hlavy.

Řešení
Při psaní kódu se jedná o tzv “magická čísla” je třeba se vyhnout za každou cenu. Pevně ​​zakódovaná čísla mají smysl v době, kdy jsou psána, ale mohou rychle ztratit veškerý význam - zejména když se někdo snaží zachovat váš kód.

Jedním řešením je zanechat komentáře, které vysvětlují číslo, ale lepší možností je převést magická čísla na konstantní proměnné (pro výpočty) nebo výčty (pro podmíněné příkazy a příkazy přepínání). Při pojmenování magických čísel se kód stává na první pohled nekonečně čitelnějším a méně náchylný ke změnám v buggy.

7. Hluboké hnízdění

Problém
Existují dva hlavní způsoby, jak skončit s hluboce vnořeným kódem: smyčky a podmíněné příkazy. Hluboko vnořený kód není vždy špatný, ale může být problematický, protože může být obtížné jej rozebrat (zejména pokud proměnné nejsou dobře pojmenovány) a je dokonce obtížnější modifikovat.

Řešení
Pokud zjistíte, že pro smyčku píšete dvojnásobek, trojnásobek nebo dokonce čtyřnásobek, pak se váš kód může snažit dosáhnout příliš daleko mimo sebe, aby našel data. Místo toho poskytněte způsob, jak se data vyžádají prostřednictvím volání funkce na jakémkoli objektu nebo modulu, který data obsahuje.

Na druhou stranu, hluboce vnořené podmíněné příkazy jsou často známkou toho, že se snažíte zvládnout příliš mnoho logiky v jedné funkci nebo třídě. Hluboké hnízdění a dlouhé funkce mají sklon jít ruku v ruce. Pokud váš kód obsahuje masivní příkazy přepínače nebo vnořené příkazy if-then-else, možná budete chtít místo toho implementovat vzor stavu stroje nebo strategie.

Hluboké hnízdo je zvláště rozšířeno mezi nezkušenými programátory her. 5 bezplatných softwarových nástrojů pro vývoj her k vytvoření vlastních her 5 bezplatných softwarových nástrojů pro vývoj her k vytvoření vlastních her bezplatný software pro vývoj her je skvělý způsob, jak zahájit výrobu videoher. Sestavili jsme nejlepší herní software na trhu. !

8. Neošetřené výjimky

Problém
Výjimky jsou silné, ale snadno zneužitelné. Líní programátoři, kteří nesprávně používají příkazy throw-catch, mohou ladění exponenciálně ztížit, ne-li nemožné. Například ignorování nebo pochování zachycených výjimek.

Řešení
Namísto ignorování nebo pochování zachycených výjimek alespoň vytiskněte stopu zásobníku výjimky, takže debuggery mají něco, s čím budou pracovat. Umožnění tichého selhání programu je recept na budoucí bolesti hlavy, zaručeno! Také dávejte přednost chytit specifické výjimky před obecnými výjimkami. Přečtěte si více v našem článku o tom, jak zacházet s výjimkami správným způsobem Jak zacházet s výjimkami Java Správným způsobem Jak zacházet s výjimkami Java správným způsobem V tomto článku se dozvíte, jaké jsou výjimky Java, proč jsou důležité, jak používat je a běžným chybám se vyhnout. .

9. Duplicitní kód

Problém
Stejnou přesnou logiku provádíte ve více nesouvisejících oblastech vašeho programu. Později si uvědomíte, že musíte tuto logiku upravit, ale nepamatujte si všechna místa, kde jste ji implementovali. Nakonec to změníte pouze na 5 z 8 míst, což má za následek buggy a nekonzistentní chování.

Řešení
Duplicitní kód je hlavním kandidátem, který se stal funkcí. Řekněme například, že vyvíjíte chatovou aplikaci a píšete toto:

String queryUsername = getSomeUsername (); boolean isUserOnline = false; for (String username: onlineUsers) if (username.equals (queryUsername)) isUserOnline = true;  if (isUserOnline) …

Někde jinde v kódu si uvědomujete, že musíte provést totéž “je tento uživatel online?” kontrola. Namísto kopírování smyčky ji můžete vytáhnout do funkce:

public boolean isUserOnline (String queryUsername) for (String username: onlineUsers) if (username.equals (queryUsername)) návrat true;  vrátit false; 

Nyní kdekoli v kódu můžete použít kontrolu isUserOnline (). Pokud budete někdy potřebovat tuto logiku upravit, můžete tuto metodu vyladit a bude se používat všude, kde se volá.

10. Nedostatek komentářů

Problém
Kód nemá nikde žádné komentáře. Žádné bloky dokumentace pro funkce, žádné přehledy použití pro třídy, žádná vysvětlení algoritmů atd. Dalo by se argumentovat, že dobře napsaný kód nepotřebuje komentáře, ale pravdou je, že i ten nejlepší napsaný kód stále potřebuje více duševní energie rozumět než anglicky.

Řešení
Cílem snadno udržovatelné kódové základny by měl být kód, který je napsán tak dobře, že to není možné potřeba komentáře, ale stále je mají. A při psaní komentářů se zaměřte na komentáře, které vysvětlují proč místo vysvětlení existuje fragment kódu co dělá to. Komentáře jsou dobré pro duši a rozum. Nezanedbávejte je.

Jak napsat kód, který nepáchne

Jak je zřejmé, většina kódových pachů pramení z nedorozumění nebo zanedbávání dobrých programovacích principů a vzorců. 10 Základní principy programování Každý programátor musí následovat 10 Základní principy programování Každý programátor musí následovat Vždy napsat kód, který může udržovat kdokoli, kdo může skončit pracovat na vašem softwaru. Za tímto účelem je zde několik zásad programování, které vám pomohou vyčistit váš akt. . Například důsledné dodržování zásady DRY eliminuje většinu duplikace kódu, zatímco zvládnutí zásady Single Responsibility téměř znemožňuje vytvářet monstrózní Boží objekty..

Doporučujeme také přečíst si článek o tom, jak psát čistší kód. 10 tipů pro psaní čistšího a lepšího kódu. 10 tipů pro psaní čistšího a lepšího kódu. Takto můžete začít psát čistší kód ještě dnes. , který se dívá na praktičtější stránku programování. Pokud nedokážete přečíst svůj vlastní kód a pochopit jej na první pohled, jak bude někdo jiný? Čistý kód je kód bez zápachu.

S čím nejvíce zápasíte, pokud jde o programování? Sdílejte s námi v komentářích níže!

Obrazový kredit: SIphotography / Depositphotos