Je o mně známo, že jsem fanouškem Junior Guru. Nejedná se jen o příručku o hledání první práce v IT, ale o celou podporující komunitu. Rád bych se tam zapojit do mentoringu, ale kapacita mých dobrovolnických aktivit naráží na limity. Nicméně měl bych jednu univerzální radu, kterou neustále opakuji a stále vídám i u lidí z praxe. V učení neexistují rychlé zkratky, ovšem tohle můžete snadno začít používat a zrychlit tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Úvod

O statické analýze kódu jsem na blogu již několikrát psal, ale opakování není nikdy dost.

Nejen v Java světě mám na mysli nástroje PMD, Checkstyle, SpotBugs, SonarQube, Coverity 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).

String currentFruit = null;
if (currentFruit == Fruit.APPLE) {
// ...

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ý warning. Ani profíci by tím nemuseli opovrhovat (ne, to nebudou zralí inženýři).

Související