रैखिक कोड अधिक पढ़ने योग्य है

• Google Testing Blog में प्रस्तुत दृष्टिकोण को चुनौती देते हुए रैखिक कोड की पठनीयता पर चर्चा करने वाला लेख
• लेखक Google Testing Blog के इस दावे से सहमत नहीं हैं कि abstraction level को अलग करने वाले functions अधिक पठनीय होते हैं
• लेखक का तर्क है कि ऊपर से नीचे तक पढ़ा जाने वाला रैखिक कोड, अलग-अलग abstraction levels के बीच आगे-पीछे जाने वाले कोड की तुलना में अधिक सहज और समझने में आसान होता है
• लेखक pizza bake करने वाले function के उदाहरण से अपना तर्क समझाते हैं और सवाल उठाते हैं कि क्या pizza bake करने वाला function oven को गरम करता है, या oven को पहले से preheat किया जाना चाहिए
• लेखक का सुझाव है कि कोड की पठनीयता abstraction levels को अलग करने वाली संरचना की वजह से नहीं, बल्कि इस वजह से आती है कि कोड का हर हिस्सा क्या करता है यह साफ़ तौर पर बताया गया हो
• लेखक रैखिक कोड में छोटे functions निकालने के खिलाफ हैं, खासकर जब उनका उपयोग केवल एक बार हो; उनका निष्कर्ष है कि इसका लाभ रैखिकता खोने की भरपाई नहीं करता
• लेखक pizza bake function से जुड़े संभावित समस्याओं की ओर भी इशारा करते हैं और सवाल करते हैं कि हर बार pizza बनाते समय नया oven क्यों बनाया जा रहा है; इससे वास्तविक कोड में performance समस्याएँ हो सकती हैं
• लेखक का सुझाव है कि oven को function का parameter होना चाहिए, उसे उपलब्ध कराना caller की ज़िम्मेदारी होनी चाहिए, और function को pizza नहीं बल्कि box लौटाना चाहिए

[GN⁺]

Hacker News की राय

• linear code और modular code की पठनीयता शैली का मामला है, और इसके लिए अच्छी समझ व संतुलित निर्णय की ज़रूरत होती है।
• जरूरत से ज़्यादा abstraction कोड के समय से पहले coupling का कारण बन सकता है।
• काम की इकाइयों को abstract करने के लिए functions निकालना algorithm को व्यवस्थित कर सकता है, लेकिन इसका उपयोग सावधानी से करना चाहिए।
• दिया गया example code सरल है और scalability कम है। reusability और unit testability पर भी विचार किया जाना चाहिए।
• जरूरत से ज़्यादा refactoring, कोड के दूसरे हिस्सों को भी खिसकाने की आवश्यकता के कारण, maintenance को और कठिन बना सकती है।
• linear code execution order का पालन करता है, इसलिए पढ़ने में आसान होता है, लेकिन बड़े codebase में इसकी scalability कम होती है।
• गहराई से nested call stack वाले संक्षिप्त functions बड़े codebase में दुःस्वप्न बन सकते हैं।
• अच्छा linear code पढ़ने में अधिक आसान होता है, लेकिन maintenance और testing अधिक कठिन हो सकते हैं।
• functions को जितना संभव हो उतना छोटा और single purpose के करीब रखना अच्छी practice है।
• कोड की संरचना को business use case के अनुरूप व्यवस्थित किया जाना चाहिए ताकि उसे आसानी से इधर-उधर ले जाया जा सके।
• linear code और modular code दोनों को linear तरीके से पढ़ा जाता है, लेकिन functions का क्रम पठनीयता को प्रभावित कर सकता है।
• वास्तविक कोड अक्सर अधिक जटिल होता है, और पाठक को विवरणों में उलझने से बचाने के लिए उच्च-स्तरीय overview की आवश्यकता होती है।