कोड की पठनीयता को घटाने वाले दृश्य जटिलता पैटर्न (2023)

• हाल ही में एक codebase की समीक्षा करते समय, कोड की गुणवत्ता अच्छी होने के बावजूद मानसिक रूप से थकाने वाला अनुभव हुआ
  • यह कोड की complexity से अधिक readability से जुड़ा हुआ था
• कोड की पठनीयता बढ़ाने के लिए 8 पैटर्न निकाले गए

कोड पठनीयता metrics और वैकल्पिक complexity metrics

• कोड पठनीयता को मापने के लिए कोई सार्वभौमिक और व्यापक रूप से उपयोग किया जाने वाला metric मौजूद नहीं है
• केवल ऐसे academic papers या व्यक्तिगत राय मौजूद हैं जिनका वास्तविक दुनिया में उपयोग नहीं होता
• नया metric बनाने के बजाय, ऐसे visual patterns पर ध्यान दिया गया जिन पर कोई भी आसानी से चर्चा कर सके
• complexity metric के लिए महत्वपूर्ण शर्तें:
  • source code snippets या individual functions पर काम करना चाहिए
  • algorithmic complexity के बजाय कोड लिखने के तरीके पर ध्यान होना चाहिए
  • style elements (जैसे variable names, whitespace, indentation आदि) पर ध्यान नहीं होना चाहिए

Halstead complexity metric

• 1970 के दशक में Maurice Halstead द्वारा विकसित कोड complexity metric
• भाषा और platform की परवाह किए बिना कोड लिखने के तरीके को संख्यात्मक रूप से मापा जा सकता है
• operators और operands की संख्या के आधार पर program की length, volume और difficulty की गणना करता है
• मुख्य मापदंड:
  • unique operators की संख्या (n1)
  • unique operands की संख्या (n2)
  • कुल operators की संख्या (N1)
  • कुल operands की संख्या (N2)
• जितने अधिक operators और operands उपयोग होंगे, कोड की complexity उतनी बढ़ेगी
• सभी भाषाओं में operators और operands की परिभाषा स्पष्ट नहीं होती, इसलिए consistent tool का उपयोग महत्वपूर्ण है

Halstead complexity से मिले insights

• छोटे functions और कम variables होने पर readability बेहतर होती है
• भाषा-विशिष्ट operators या syntactic sugar का उपयोग न्यूनतम रखें
• functional programming में chains (map/reduce/filter आदि) बहुत लंबी हो जाएँ तो readability घटती है

Cognitive Complexity

• SonarSource द्वारा विकसित complexity metric
• कोड को पढ़ने में कठिनाई को अधिक सटीक रूप से मापने का प्रयास
• तीन मुख्य सिद्धांत:
  1. shorthand constructs पढ़ने की कठिनाई को कम करते हैं
  2. non-linear flow में रुकावट कठिनाई बढ़ाती है
  3. nested control flow कठिनाई बढ़ाता है

Cognitive Complexity से मिले insights

• shorthand constructs संक्षिप्त होते हैं, लेकिन उनमें संभावित bugs का जोखिम हो सकता है
• conditional statements और logical operators का अत्यधिक उपयोग readability को घटाता है
• exception handling कोड complexity बढ़ाने का प्रमुख कारण है
• goto से सामान्यतः बचना चाहिए, लेकिन कुछ परिस्थितियों में यह उपयोगी हो सकता है
• nested control structures को जहाँ तक संभव हो कम करना चाहिए

functions का आकार, patterns और variables

• function का दृश्य "shape" कोड readability में महत्वपूर्ण भूमिका निभाता है
• readability बढ़ाने के तीन सिद्धांत:
  1. स्पष्ट और ठोस variable names का उपयोग
  • variable shadowing से बचें
  • ऐसे नाम उपयोग करें जिन्हें दृश्य रूप से अलग पहचाना जा सके (i, j जैसे मिलते-जुलते नामों से बचें)
  2. variables की lifespan कम करें
  • variable का scope जितना छोटा हो, उतना अच्छा
  • जो variables function boundary के पार लंबे समय तक बने रहते हैं, वे complexity बढ़ाते हैं
  3. परिचित code patterns का पुन: उपयोग
  • consistent code patterns बनाए रखने से readability बेहतर होती है
  • नए approaches की बजाय पहले से परिचित patterns को प्राथमिकता दें

कोड readability सुधारने वाले 8 पैटर्न

1. lines/operators/operands की संख्या कम करें – छोटे functions और कम variables readability बढ़ाते हैं
2. नए approaches से बचें – codebase में परिचित patterns बनाए रखें
3. grouping – लंबे function chains, iterators आदि को helper functions में बाँटें
4. conditional statements को सरल रखें – conditions छोटी रखें और logical operators के मिश्रण को न्यूनतम करें
5. goto को न्यूनतम रखें – आवश्यकता होने पर केवल error handling में सीमित रूप से उपयोग करें
6. nesting कम करें – nested logic को घटाएँ और ज़रूरत होने पर function में अलग करें
7. स्पष्ट variable names का उपयोग करें – ठोस और non-overlapping variable names रखें
8. variables की lifespan कम करें – उन्हें function के भीतर कम समय तक रखें और function boundaries के पार न जाने दें

निष्कर्ष

• कोड readability, कोड quality का एक महत्वपूर्ण तत्व है
• Halstead और Cognitive Complexity readability समस्याओं को संख्यात्मक रूप से समझने और सुधार की दिशा सुझाने में मदद कर सकते हैं
• संक्षिप्त और स्पष्ट कोड लिखने से maintenance आसान होता है और bugs की संभावना कम होती है
• सर्वोत्तम कोड लेखन का मतलब है सादगी, consistency और clarity को प्राथमिकता देना

[GN⁺]

Hacker News राय

• map, reduce, filter जैसी functional programming संरचनाओं को जोड़ना संक्षिप्त होता है, लेकिन लंबी chain अक्सर readability को नुकसान पहुंचाती है

  • यह लेख में निहित बात नहीं थी
  • यह एक सामान्य शिकायत जैसी लगती है कि जो परिचित नहीं है, उसे बुरा मान लिया जाता है
  • थोड़ी-सी आदत पड़ जाए तो इसे पढ़ना और लिखना दूसरे तरीकों से आसान हो जाता है
  • functional programming की बुनियाद सीखना महत्वपूर्ण है
  • Monad समझाने की ज़रूरत नहीं है, लेकिन map और filter को यूँ ही कोसने से बचने लायक परिचय होना चाहिए

• अच्छे कोड का एक महत्वपूर्ण पहलू गुणात्मक और साहित्यिक होता है

  • गणितीय सोच वाले प्रोग्रामरों और अकादमिक लोगों के लिए यह असहज हो सकता है
  • दोस्तोयेव्स्की और वुडहाउस दोनों पसंद हो सकते हैं, लेकिन उनकी लेखन शैली बहुत अलग है
  • किसी codebase की शैली को समझने में समय लगता है

• कोड पढ़ते समय सबसे थकाने वाली समस्या mutability है

  • किसी variable को सिर्फ एक बार "fix" कर पाने की क्षमता एक बड़ा उपहार है
  • किसी method को समझने की प्रक्रिया 0% से 100% तक एकसार बढ़नी चाहिए
  • GOTO हानिकारक होने का कारण यह है कि mutable variables की state जानना कठिन हो जाता है

• छोटे functions और कम variables आम तौर पर पढ़ने में आसान होते हैं

  • "readability" पर फोकस अक्सर micro-readability की तरफ झुक जाता है
  • इससे कोड जरूरत से ज़्यादा बिखर जाता है
  • APL परिवार की भाषाएँ इसका विपरीत छोर हैं

• TypeScript कोड पढ़ना कठिन बना देता है

  • अगर data model "atomic" बना रहे तो यह ठीक है
  • type inference पर निर्भर रहने से fields को उनके मूल स्थान तक ट्रैक करना मुश्किल हो जाता है

• getOddness4 फ़ंक्शन असममिति पैदा करता है

  • getOddness2 फ़ंक्शन सममित विकल्प देता है

• लेख दिलचस्प है, लेकिन पूरी तरह संतोषजनक नहीं

  • language-specific operators या syntax sugar के उपयोग से बचने वाली राय से सहमत नहीं हूँ
  • map, reduce, filter जैसी संरचनाएँ सही तरीके से इस्तेमाल हों तो दूसरे operators की जगह ले सकती हैं और "volume" कम करती हैं

• readability को परिभाषित करने की कोशिश सराहनीय है

  • कई लोगों पर testing करके readability के वास्तविक आयाम खोजे जा सकते हैं

• कोड की complexity को syntax tree के आकार से व्यक्त किया जा सकता है

  • local complexity में कमी का कुल complexity पर बहुत बड़ा असर नहीं पड़ता

• लंबी function chain या callback को छोटे समूहों में बाँटना और अच्छे नाम वाले variables का उपयोग करना बेहतर है

  • efficiency के मामले में दोनों versions समान हैं
  • अंतर compiler में है