Takélint, statický analyzátor kóduPokročilý
Definice
Linter je nástroj statické analýzy, který kontroluje zdrojový kód bez jeho spuštění a upozorňuje na porušení pravidel, podezřelé konstrukce nebo nekonzistentní styl. Pomáhá zachytit chyby dřív než při testování či code review a často se spouští v editoru, před commitem nebo v CI pipeline.
Co linter zachytí dřív než překladač nebo testy
Linter prochází zdrojový kód a hledá vzory, které jsou podezřelé, nekonzistentní nebo v rozporu s pravidly projektu. Typicky upozorní na nepoužité proměnné, nedosažitelný kód, stínování názvů, chybějící ošetření chyb, porušení stylu nebo konstrukce, které v daném jazyce často vedou k chybám. Linter nemusí program spouštět, takže se hodí pro rychlou kontrolu při psaní i v automatizovaném buildu.
Linter se liší od kompilátoru tím, že často kontroluje i věci, které jsou syntakticky platné. Kód může projít překladem a přesto být rizikový, špatně čitelný nebo v rozporu s dohodnutým stylem. V JavaScriptu může linter například zakázat volné porovnání ==, i když jazyk takový zápis povoluje.
Proč linter není jen formátovač
Formátovač řeší hlavně vzhled kódu: odsazení, zalamování řádků, mezery nebo uvozovky. Linter řeší širší sadu pravidel. Některá pravidla jsou čistě stylová, jiná mají bezpečnostní, výkonový nebo architektonický dopad. V praxi se proto často používají oba nástroje: formátovač automaticky sjednotí zápis a linter upozorní na problém, který vyžaduje rozhodnutí vývojáře.
Rozhraní mezi linterem a formátovačem není vždy ostré. Některé lintery umí část nálezů automaticky opravit, například seřadit importy nebo odstranit nepoužitý import. Jiné nálezy automatickou opravu nemají, protože nástroj neví, jaký záměr autor kódu měl. Pravidlo může správně ukázat podezřelé místo, ale konečné posouzení zůstává na člověku.
Místo linteru ve vývojovém workflow
Linter má největší hodnotu tam, kde se spouští brzy a pravidelně. Vývojář ho může vidět přímo v editoru, tým ho může spouštět před commitem a CI pipeline může odmítnout pull request s porušenými pravidly. Díky tomu se část diskuse v code review přesune z osobních preferencí do sdílené konfigurace.
Konfigurace linteru bývá součástí repozitáře, aby všichni pracovali se stejnými pravidly. U větších týmů je důležité pravidla zavádět postupně. Příliš přísný linter ve starém projektu snadno vyrobí tisíce hlášení, která nikdo nečte. Rozumný postup je nejprve vynutit pravidla pro nově měněný kód a technický dluh snižovat po menších částech.
Kde linter vytváří tření
Linter může škodit, když tým bez rozmyslu zapne pravidla, která neodpovídají jazyku, frameworku nebo stylu projektu. Výsledkem jsou potlačená varování, nečitelná obcházení pravidel a frustrace. Užitečný linter má málo falešných poplachů, srozumitelná hlášení a jasnou cestu, jak výjimku zdůvodnit.
Linter také nenahrazuje testy, typový systém ani code review. Statická pravidla neumí ověřit všechny běhové stavy a často nerozumí obchodní logice aplikace. Dobrý linter je proto filtr na běžné chyby a nekonzistence, ne důkaz správnosti programu.
Příklady z praxe
Varování v editoru při psaní podmínky
Vývojář upraví podmínku v JavaScriptu a linter v editoru okamžitě označí použití operátoru ==. Kód by se spustil, ale implicitní převody typů mohou způsobit nečekané chování. Po změně na === kontrola projde a pravidlo zůstane konzistentní v celém projektu.
// pravidlo například zakazuje volné porovnání if (userId == 0) { grantGuestAccess(); } // opravená varianta if (userId === 0) { grantGuestAccess(); }Nepoužitá proměnná zastaví pull request
Tým přidá do CI kroku kontrolu Python kódu a linter označí proměnnou debug jako nepoužitou. Pull request kvůli tomu neprojde, i když funkce technicky funguje. Autor proměnnou odstraní a diff zůstane menší a čitelnější.
def send_email(address, subject): message = build_message(subject) debug = True return smtp_send(address, message)
Časté omyly
- MýtusLinter je jen nástroj na mezery a odsazení.
- Ve skutečnostiLinter může kontrolovat styl, ale jeho role bývá širší. Často odhaluje nepoužité proměnné, podezřelé podmínky, riziková API nebo porušení týmových pravidel.
- MýtusKdyž kód projde linterem, je správně.
- Ve skutečnostiLinter potvrzuje jen soulad s nastavenými statickými pravidly. Program může mít chybu v logice, špatné ošetření dat nebo problém v produkční konfiguraci, který linter vůbec nevidí.
- MýtusNejlepší je zapnout všechna dostupná pravidla.
- Ve skutečnostiPříliš mnoho pravidel zvyšuje šum a vede k ignorování varování. Užitečnější je sada pravidel, která tým chápe, udržuje a opravdu vynucuje.
Časté dotazy
- Kdy má smysl přidat linter do existujícího projektu?
- Linter se vyplatí přidat hned na začátku projektu, protože pravidla pak nevytvoří velký jednorázový dluh. Linter lze přidat i do staršího repozitáře, ale lepší je začít s menší sadou pravidel a postupně přitvrzovat. Praktický kompromis je vynucovat kontrolu jen na nově změněných souborech nebo dočasně ponechat některá pravidla jako varování místo chyb.
- Má linter nahrazovat formatter?
- Linter může částečně kontrolovat styl, ale formatter je vhodnější pro automatické sjednocení vzhledu kódu. Linter má hlídat především podezřelé konstrukce, konzistenci a týmová pravidla, zatímco formatter má řešit mechanické formátování bez diskuse. Kombinace obou nástrojů bývá stabilnější než snaha donutit linter opravovat každý detail zápisu.
- Má linter v CI pipeline blokovat merge?
- Linter v CI pipeline má obvykle selhat u pravidel, která tým považuje za závazná. Méně jistá nebo nově zaváděná pravidla mohou zůstat jako varování, aby se ukázal jejich dopad bez blokování práce. Důležité je rozlišit chyby, které brání sloučení kódu, od doporučení, která mají vývojáři řešit průběžně.
- Může linter najít bezpečnostní chyby?
- Linter může pomoci se statickou částí bezpečnosti, například upozornit na nebezpečné API, podezřelé porovnání nebo zakázaný vzor práce s daty. Linter ale nezná všechny vstupy, konfigurace a běhové scénáře aplikace. Bezpečnostní kontrola proto potřebuje také code review, testy, skenování závislostí a podle typu systému i specializovanou analýzu.
Zdroje
- Lint (software)(otevře se v novém okně)
- PEP 8 – Style Guide for Python Code(otevře se v novém okně)
- TSConfig Reference(otevře se v novém okně)
- Code analysis overview(otevře se v novém okně)
Související pojmy
