Clean code — maqsadi tushunarli, o‘zgartirish xavfi boshqariladigan va ortiqcha murakkablikdan xoli dastur kodini tavsiflovchi umumiy tushuncha. U bitta qat’iy format yoki uslub emas. O‘qiluvchan nomlar, aniq responsibility, nazoratlangan dependency, xatolarni to‘g‘ri boshqarish va testlanadigan behavior uning amaliy belgilaridir.
Nomlash
Nom domain ma’nosini va birlikni bildiradi. timeout_ms tdan aniqroq; active_users collection ekanini ko‘rsatadi. data, manager yoki process kabi umumiy nomlar kontekst yetarli bo‘lmasa ma’noni yashiradi.
Bir tushuncha uchun bir xil atama ishlatiladi. customer, client va user aslida bir entity bo‘lsa aralash nomlash noto‘g‘ri model taassurotini beradi. Agar domain’da ular farqli rol bo‘lsa farq type va nomda aniq ko‘rsatiladi.
Funksiya va responsibility
Funksiya bitta tushunarli maqsadga ega bo‘lishi va nomi bilan xatti-harakatini ifodalashi kerak. “Bitta ish” qator soni bilan o‘lchanmaydi; domain responsibility va abstraction darajasi muhim. Juda mayda funksiyalarga parchalash control flow’ni yuzlab sakrashga aylantirishi mumkin.
| Muammo belgisi | Mumkin bo‘lgan sabab |
|---|---|
| Ko‘p boolean flag | Bir nechta behavior bitta API’da |
| Uzoq parameter ro‘yxati | Yashirin domain obyekt yetishmaydi |
| Aralash I/O va hisob | Boundary ajratilmagan |
| Takroriy switch | Polymorphism yoki mapping ehtiyoji |
| Global state | Dependency va lifecycle noaniq |
Refactor symptomga ko‘r-ko‘rona pattern qo‘llamaydi; avval change reason va invariant tushuniladi.
Izoh va hujjat
Comment kod nima qilayotganini takrorlashdan ko‘ra nega noodatiy qaror qilinganini tushuntiradi. Murakkab workaround ticket, protocol talabi yoki performance sababi bilan bog‘lanadi. Eskirgan comment noto‘g‘ri koddan ham chalg‘ituvchi bo‘lishi mumkin.
Public API contract, error semantics va units hujjatlashtiriladi. O‘z-o‘zini tushuntiruvchi kod ham tashqi behavior va business constraintni to‘liq ifodalamasligi mumkin.
Error handling
Xato jim yutilmaydi. Domain error, retryable infrastructure error va programmer invariant buzilishi farqlanadi. Catch block kontekst qo‘shadi yoki recovery qiladi; faqat loglab qayta tashlash duplicate log yaratishi mumkin.
Null yoki sentinel qiymatning ma’nosi type’da ifodalanadi. Exception umumiy control flow uchun haddan tashqari ishlatilmasa ham, errorni noto‘g‘ri default bilan almashtirish data corruption keltirishi mumkin.
Dependency
Core business logic database driver va HTTP frameworkdan imkon qadar ajratiladi. Boundary interface test, replacement va evolyutsiyani osonlashtiradi. Har class uchun interface yaratish esa ceremony va navigatsiyani oshiradi; real variation yoki boundary bo‘lganda abstraction qiymatli.
Dependency direction yuqori darajadagi policy’ni past implementation detailga qattiq bog‘lamaydi. Configuration va side effect explicit kiradi, yashirin singletondan olinmaydi.
Test va o‘zgaruvchanlik
Clean code faqat test o‘tishi bilan aniqlanmaydi, ammo testlar refactoring safety net beradi. Behavior’ga qaratilgan test internal tuzilma o‘zgarganda ortiqcha yiqilmaydi. Kuchsiz yoki flaky suite “toza” ko‘ringan refactor regressionini yashiradi.
Code review nomlash, control flow, security, performance va operatsion kuzatuvni ko‘radi. Formatter va linter mexanik uslubni avtomatlashtirib, reviewni semantik masalaga qoldiradi.
Kontekst va muvozanat
Embedded interrupt handler, data pipeline va web controller uchun clean code mezonlari bir xil emas. Performance-critical hot path’da allocationni kamaytirish uchun murakkabroq tuzilma zarur bo‘lishi mumkin; benchmark va izoh bilan asoslanadi.
Qisqa kod doim sodda kod emas. Bir qatorli murakkab expression ko‘p qadamli aniq koddan yomon o‘qilishi mumkin. Abstraksiya ham duplicationni kamaytirib, noto‘g‘ri umumlashtirilsa couplingni oshiradi.
Bog‘liq tushunchalar
Readability, Refactoring, Technical debt, SOLID, Code review, Naming convention, Maintainability