Přejít k navigační liště

Zdroják » Různé » Enum a statická analýza kódu

Enum a statická analýza kódu

Články Různé

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Text vyšel původně na webu autora.

Úvod

O statické analýze kódu jste už možná slyšeli. Nejen v Java světě, mám na mysli nástroje PMDCheckstyleSpotBugsSonarQubeCoverity Scan a mnohé další. Nemluvě o radách, které vám dává samotné IDE. Neříkám, ať si instalujete všechno a hned. Doporučoval bych sledovat alespoň to, co vám poradí IntelliJ IDEA spolu s SonarLint pluginem. Místopřísežně prohlašuji, že po letech programování se učím stále něco nového. Nemyslím si, že byste měli rezignovat na čtení knih jako Effective Java, Joshua Bloch, ale proč si nezapnout automatickou kontrolu, že?

Ještě bych chtěl dodat, že nejde o slepé následování pravidel. Snažil jsem se naučit trochu fotografovat, tam jde taky o to osvojit si základní osvědčená pravidla kompozice a expozice. Jasné, umělci pravidla porušují, ale vědí (alespoň intuitivně) proč to dělají a čeho tím dosáhnou.

Enum

Pojďme se podívat konkrétně na pravidlo Enum values should be compared with ==. Připomeňme, že operátor == porovnává reference (místo v paměti) zatímco k porovnání ekvivalence objektů slouží metoda equals. Občas to dožene i ostřílené programátory. Ano, stalo se to i mně. Na svoji obhajobu uvádím, že to bylo v rámci refaktoringu a kompilátor si na to nestěžoval. Tohle pravidlo by však podobné chybě dokázalo zabránit.

Jak pravidlo uvádí, použití == nad enum:

  • vrací stejný výsledek porovnání (obsahu) jako equals
  • je více null-safe než equals()
  • poskytuje kontrolu už v době kompilace (statickou) než kontrolu až za běhu

Následující kód se nezkompiluje. A i když změníte String za Fruit, tak za běhu nedostanete NullPointerException (na rozdíl od equals, kde si musíte dávat pozor na pořadí, dávat konstanty na první místo nebo nejprve kontrolovat, zda proměnná není null).

<strong>String</strong> currentFruit <strong>=</strong> <strong>null</strong><strong>;</strong>
<strong>if</strong> <strong>(</strong>currentFruit <strong>==</strong> <strong>Fruit</strong><strong>.</strong>APPLE<strong>)</strong> <strong>{</strong>
<em>// ...</em>
Code language: HTML, XML (xml)

Závěr

Doporučuji začít používat nějakou statickou analýzu kódu. Sledujte, co vám to nadhodí. Pravidla můžete selektivně odebírat či dokonce přidávat. Zároveň lze měnit jejich závažnost. Ze začátečníků to mávnutím kouzelného proutku profíky neudělá, ale učení může výrazně zrychlit. Minimálně uděláte dojem s odevzdaným úkolem na pohovor (alespoň u mě 😉), když to nebude samý warningAni profíci by tím nemuseli opovrhovat (ne, to nebudou zralí inženýři).

Komentáře

Odebírat
Upozornit na
guest
0 Komentářů
Nejstarší
Nejnovější Most Voted

TypeScript 7 v Go: rychlejší buildy, chybějící API

Betaverze TypeScriptu 7.0 ukazuje víc než rychlejší tsc. Microsoft převádí kompilátor a jazykovou službu z původní kódové základny psané v TypeScriptu a běžící jako JavaScript do Go, přidává paralelní typovou kontrolu a připravuje novou editorovou část postavenou na LSP. Pro část nástrojů ale nepůjde o prostou výměnu binárky: TypeScript 7 zatím nemá stabilní náhradu dnešního Compiler API.

Prolog nezmizel. Jen dnes žije v jiných nástrojích

Prolog nezmizel. Jeho hlavní myšlenku dnes potkáváme v nástrojích, které se Prologu na první pohled nepodobají: v CodeQL pro analýzu kódu, v Rego pro policy-as-code, v Z3 pro práci s omezeními a v Leanu pro formální důkazy. Každý řeší jiný problém, ale všechny připomínají totéž: někdy je lepší popsat vztahy, pravidla, omezení nebo tvrzení než vrstvit další if.