ifs को ऊपर ले जाना और fors को नीचे ले जाना

 (matklad.github.io)
1 पॉइंट द्वारा GN⁺ 2023-11-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें

फ़ंक्शन के भीतर conditionals को ऊपर ले जाना

  • अगर किसी फ़ंक्शन के भीतर if conditional है, तो उसे caller की ओर ले जाने पर विचार करें.
  • फ़ंक्शन अगर precondition को अंदर जाँचकर condition पूरी न होने पर 'कुछ भी न करने' के बजाय, caller को precondition जाँचने दें ताकि type के माध्यम से यह सुनिश्चित हो सके कि precondition पूरी हुई है.
  • precondition को विशेष रूप से 'ऊपर ले जाने' से कुल मिलाकर जाँच का काम कम हो सकता है, और यही इस नियम की एक मुख्य प्रेरणा है.

loops को नीचे ले जाना

  • यह data-oriented सोच से निकला नियम है, जिसमें object के 'batch' concept को लाया जाता है, batch operation को base case माना जाता है, और scalar version को batch version का एक special case माना जाता है.
  • performance improvement इसका मुख्य लाभ है; startup cost को amortize किया जा सकता है और processing order में flexibility मिल सकती है.
  • उदाहरण के लिए, FFT-आधारित polynomial multiplication में कई बिंदुओं पर एक साथ polynomial का evaluation करना, अलग-अलग evaluation करने की तुलना में तेज़ हो सकता है.

GN⁺ की राय

  • इस लेख की सबसे महत्वपूर्ण बात यह है कि यह software development में performance और code clarity बेहतर करने के लिए दो programming rules, 'conditionals को ऊपर ले जाना' और 'loops को नीचे ले जाना', पेश करता है.
  • ये नियम code readability बढ़ाने, performance optimize करने और bugs की संभावना घटाने में मदद करते हैं.
  • software engineering की complexity को manage करने और efficient code लिखने के तरीकों पर insight देने के कारण यह लेख कई developers के लिए दिलचस्प और उपयोगी है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-16
Hacker News राय
  • डेटा-ओरिएंटेड डिज़ाइन पर दी गई सलाह के खिलाफ प्रतिक्रिया हैरान करने वाली लगती है। ज़्यादातर फ़ोरम उपयोगकर्ता वेब एप्लिकेशन लिखते हैं, इसलिए यह सलाह उन्हें निरर्थक लग सकती है। अगर आपको अपने रोज़मर्रा के काम में instruction cache के बारे में सोचने की ज़रूरत नहीं पड़ती, तो इस सलाह को नज़रअंदाज़ कर देना चाहिए। Mike Acton का "Typical C++ Bullshit" देखें, तो इस सलाह की अहमियत समझी जा सकती है.
  • एक राय यह है कि प्रोग्रामर कोड को "छोटी इकाइयों" में सुंदर बनाने पर तो ध्यान देते हैं, लेकिन पूरे codebase के उचित डिज़ाइन पर पर्याप्त ध्यान नहीं देते। अगर किसी function का नाम अच्छा है, उसका interface अच्छा है, उसका उद्देश्य स्पष्ट है, वह ठीक से documented है, और वह side effects का अत्यधिक इस्तेमाल नहीं करता, तो function थोड़ा बिखरा हुआ हो या उसमें if और for की व्यवस्था कैसी है, इस पर बहुत ज़्यादा ध्यान नहीं देना चाहिए.
  • विज्ञान क्षेत्र से प्रोग्रामिंग शुरू करने वाले एक व्यक्ति की राय है कि छोटे optimization महत्वपूर्ण होते हैं। for loop के क्रम का गलत इस्तेमाल simulation के runtime को 1 हफ़्ते से घटाकर 1 घंटे तक ला सकता है। ऐसी पृष्ठभूमि वाले लोग for और if के क्रम को सहज रूप से optimize करते हैं.
  • एक राय यह है कि अगर कोई "container" है, तो container पर function लिखने के बजाय उस domain-level "Thing" पर function लिखने चाहिए जिसे container अपने भीतर रखता है। इससे कोड अधिक flexible बनता है, और core domain तथा application concerns के बीच अंतर अधिक स्पष्ट होता है.
  • if को ऊपर खिसकाने का एक नुकसान यह है कि function की preconditions और postconditions को function definition में सीधे देख पाना मुश्किल हो जाता है। बड़े प्रोजेक्ट्स में ऐसे function अपने अभिप्रेत context के बाहर दोबारा इस्तेमाल किए जा सकते हैं और bugs पैदा कर सकते हैं। contract framework का इस्तेमाल एक समाधान हो सकता है, लेकिन तब contract और code में conditions को दो बार लिखना पड़ता है.
  • Rust भाषा के उदाहरण में, Rust का मज़बूत type system दूसरे language में ज़रूरी defensive programming की आवश्यकता को रोकता है। किसी C programmer का function में दिए गए pointer की वैधता जाँचे बिना NULL reference उत्पन्न कर देना वांछनीय नहीं है। कुछ if नीचे नहीं बल्कि ऊपर होने चाहिए, और errors को सही तरह propagate होना चाहिए.
  • एक राय थी कि लेख शायद किसी खास code example तक ले जाएगा, लेकिन वास्तव में ऐसा नहीं हुआ। अपेक्षित code example की जगह एक दूसरा उदाहरण प्रस्तुत किया गया.
  • उचित context के बिना यह सलाह अजीब, बल्कि ख़राब सलाह भी हो सकती है। for loop और if statement दोनों ही control-flow operations हैं, इसलिए लेख के कुछ दावे अर्थहीन लगते हैं। performance से जुड़ा दावा सबसे मज़बूत है, लेकिन सामान्य सलाह के संदर्भ में इसे सबसे अंत में सोचना चाहिए.
  • एक राय यह है कि यह निश्चित नहीं कहा जा सकता कि ऐसे सामान्य नियम वास्तविक code पर लागू हो सकते हैं या नहीं। अक्सर इन नियमों को ग़लत dogma की तरह देखा जाता है, और युवा प्रोग्रामर इन्हें ग़लत ढंग से अपनाकर और ख़राब code लिख सकते हैं। कई बार condition walrus पर निर्भर होती है, इसलिए if को ऊपर नहीं ले जाया जा सकता.
  • precondition if को caller के पास खिसकाना एक भयानक विचार है। कुछ विशेष मामलों में यह अच्छा हो सकता है, लेकिन सामान्य स्थिति में यह नहीं चाहिए। libraries में preconditions को बाहरी boundary पर जाँचना चाहिए ताकि अंदरूनी implementation बिना आंतरिक assumptions के आगे बढ़ सके। caller की जाँच पर निर्भर रहना इस उद्देश्य को निष्फल कर देता है.