Linter

Linter — source code’ni ishga tushirmasdan tahlil qilib, xato ehtimoli, uslub buzilishi, xavfli konstruktsiya va loyiha qoidalariga mos kelmaydigan joylarni aniqlaydigan vosita.

Linter compilerga o‘xshab code’ni parse qilishi mumkin, ammo uning asosiy vazifasi executable yaratish emas. U developerga erta va avtomatik fikr bildiradi.

“Lint” atamasi tarixan C tili uchun yaratilgan statik tahlil vositasi nomidan kelib chiqqan.

Nimalarni tekshiradi?

Linter qoidalari:

syntaxga yaqin xatolar;
unused variable;
unreachable code;
noto‘g‘ri comparison;
shadowing;
naming;
import tartibi;
xavfli API;
security pattern;
complexity;
framework best practice;
formattingga yaqin uslub

ni qamrab olishi mumkin.

Static analysis

Linter source code’ni runtime’siz tahlil qiladi.

Bosqichlar:

file o‘qiladi;
lexer va parser ishlaydi;
AST yaratiladi;
scope va symbol ma’lumoti olinadi;
qoidalar node’lar ustida ishlaydi;
xabar source location bilan chiqariladi.

Murakkab linter type information va control-flow graphdan ham foydalanadi.

Syntax error va lint error

Syntax error kodning grammar bo‘yicha yaroqsizligini bildiradi.

Lint warning kod syntactically to‘g‘ri, ammo shubhali ekanini bildirishi mumkin.

Misol:

if value = 10

ba’zi tilda syntax error.

if value == value

syntax to‘g‘ri, ammo mantiqan shubhali lint xabari.

Unused code

Linter:

unused import;
unused variable;
unused function;
dead assignment;
unreachable branch

ni topishi mumkin.

Bu code’ni ixcham saqlaydi va noto‘g‘ri yozilgan nomni aniqlaydi.

Ba’zi public API reflection orqali ishlatilgani sabab false positive bo‘lishi mumkin.

Naming rule

Loyiha naming convention belgilaydi:

class — PascalCase;
function — snake_case yoki camelCase;
constant — UPPER_CASE;
private member — maxsus prefix.

Linter barcha faylda izchillikni tekshiradi.

Naming faqat kosmetika emas; code qidirish va API tushunarliligiga ta’sir qiladi.

Type-aware linting

Type checker yoki compiler service bilan integratsiya qilingan linter quyidagilarni aniqlaydi:

mavjud bo‘lmagan property;
noto‘g‘ri argument;
null ehtimoli;
incompatible return;
promise’ni await qilmaslik;
resource type misuse.

Type-aware lint oddiy AST tahlilidan sekinroq.

Control-flow analysis

Linter branchlar bo‘ylab qiymat holatini kuzatadi.

Misol:

if user is null:
    print(user.name)

Null dereference ehtimolini aniqlaydi.

Murakkab dynamic code’da to‘liq aniqlik mumkin emas.

Security linting

Security qoidalari:

hardcoded secret;
SQL string concatenation;
shell injection;
weak crypto;
insecure random;
path traversal;
unsafe deserialization;
disabled TLS verification;
eval;
permissive CORS

kabi patternlarni topishi mumkin.

Linter security auditning to‘liq o‘rnini bosmaydi.

Framework qoidalari

React hook tartibi, Django model, Android lifecycle yoki boshqa framework uchun maxsus pluginlar mavjud.

Plugin framework semantikasini biladi.

Generic linter ko‘rmaydigan xatolarni aniqlaydi.

Code style

Linter:

maximum line length;
indentation;
quote turi;
semicolon;
import grouping;
blank line;
comment format

ni tekshirishi mumkin.

Ammo zamonaviy workflow’da formatting vazifasi ko‘pincha formatterga beriladi.

Linter va formatter

Jihat	Linter	Formatter
Maqsad	Xato va qoida tahlili	Code ko‘rinishini avtomatik o‘zgartirish
Semantic tahlil	Bo‘lishi mumkin	Odatda cheklangan
Warning	Bor	Formatni bevosita tuzatadi
Security qoida	Mumkin	Yo‘q
Style	Tekshiradi	Standartlashtiradi

Ikkalasi birga ishlatiladi.

Auto-fix

Ba’zi lint xabari avtomatik tuzatiladi.

Misollar:

import tartibi;
keraksiz import;
quote;
oddiy modern syntax;
explicit boolean simplification.

Semantikani o‘zgartirishi mumkin bo‘lgan fix review qilinadi.

Rule severity

Qoida:

off;
info;
warning;
error

sifatida sozlanadi.

CI odatda error mavjud bo‘lsa buildni to‘xtatadi.

Har warningni error qilish legacy loyihada ish jarayonini qiyinlashtirishi mumkin.

Configuration

Linter config:

enabled rules;
severity;
file pattern;
ignore;
language version;
environment;
globals;
plugin;
parser option

ni belgilaydi.

Monorepo’da root config va package-specific override bo‘lishi mumkin.

Ignore

Generated code, vendor dependency va build output lintdan chiqariladi.

Ignore juda keng bo‘lsa muhim source tekshirilmaydi.

File ichida qoida o‘chirilsa sabab comment bilan yoziladi.

Inline suppression

Aniq qatorda false positive bo‘lsa qoida vaqtincha o‘chiriladi.

Yaxshi suppression:

eng kichik scope;
aniq rule ID;
sabab;
kerak bo‘lsa issue reference.

Barcha lintni global o‘chirish maqsadga zid.

False positive

Linter xavf deb belgilagan, amalda to‘g‘ri kod false positive hisoblanadi.

Sabablar:

dynamic behavior;
reflection;
framework magic;
incomplete type;
generated API;
analysis cheklovi.

Rule sozlanadi, code aniqroq yoziladi yoki lokal suppression qo‘llanadi.

False negative

Haqiqiy muammo linter tomonidan topilmasligi false negative.

Linter barcha runtime input va biznes mantiqni tushunmaydi.

Test, review, type checking, security scanning va monitoring baribir kerak.

Editor integratsiyasi

Linter language server yoki extension orqali code yozilayotgan paytda xabar beradi.

Afzalligi:

xato erta topiladi;
source location aniq;
quick fix;
CI’gacha kutish shart emas.

Editor va CI bir xil config hamda versiyadan foydalanishi kerak.

Pre-commit

Commitdan oldin o‘zgargan fayllar lint qilinadi.

Bu tez feedback beradi.

Butun repository linti CI’da bajarilishi mumkin.

Pre-commitni chetlab o‘tish mumkin bo‘lgani sabab server-side CI asosiy nazorat bo‘lib qoladi.

CI

Pipeline:

dependency o‘rnatiladi;
aniq linter versiyasi ishlatiladi;
config yuklanadi;
report chiqariladi;
error bo‘lsa job failure.

Report code annotation yoki SARIF formatida platformaga yuborilishi mumkin.

Baseline

Eski loyihada minglab lint xatoni birdan tuzatish qiyin.

Baseline mavjud xatolar ro‘yxatini vaqtincha qabul qiladi. Yangi xatolar bloklanadi, eski xatolar bosqichma-bosqich kamaytiriladi.

Baseline doimiy bahona bo‘lib qolmasligi kerak.

Performance

Katta repository linti sekin bo‘lishi mumkin.

Optimizatsiya:

cache;
faqat o‘zgargan file;
parallelism;
type-aware va syntax-only bosqichlarni ajratish;
generated file’ni ignore;
daemon yoki language server.

Natija reproducible bo‘lishi kerak.

Custom rule

Tashkilot o‘z arxitektura qoidalarini plugin sifatida yozishi mumkin.

Misollar:

controller database’ga to‘g‘ridan-to‘g‘ri murojaat qilmasin;
maxfiy log field taqiqlansin;
deprecated internal API ishlatilmasin;
ma’lum annotation majburiy.

Custom rule source structure o‘zgarsa yangilanadi.

Linter va compiler warning

Compiler warning ko‘pincha til va code generation bilan yaqin bog‘liq.

Linter:

tezroq yangilanadigan qoidalar;
style;
framework;
security;
loyiha pluginlari

bilan kengroq ishlashi mumkin.

Ular bir-birini to‘ldiradi.

Diagnostika

Linter noto‘g‘ri ishlasa:

linter version;
config qayerdan yuklandi;
parser;
language version;
plugin;
type project;
ignore pattern;
cache;
editor va CI farqi;
generated code

tekshiriladi.

“Localda toza, CI’da xato” holati odatda versiya, config, path yoki environment farqidan keladi.

Bog‘liq tushunchalar

Static analysis, AST, Type checking, Code style, Formatter, Auto-fix, CI, Pre-commit, Security scanning, Compiler warning