"Clean" Code, Horrible Performance (2023)
“Clean Code” शैली के object‑oriented design की आलोचना यह कहती है कि छोटे methods, गहरी polymorphic hierarchies, और छिपी हुई internals पर इसका ज़ोर CPU caches के खिलाफ जाकर और indirection बढ़ाकर खराब performance ला सकता है। जवाब में commenters कहते हैं कि इन patterns का उद्देश्य readability और maintainability बढ़ाना था, और असली bottlenecks अक्सर कहीं और होते हैं (जैसे network I/O, heavy frameworks), न कि virtual dispatch में। व्यापक थीम यह है कि DRY, छोटे functions, और interfaces जैसी coding “principles” केवल तभी उपयोगी हैं जब उन्हें किसी विशिष्ट domain और constraints के अनुसार judgment के साथ लागू किया जाए, न कि dogma की तरह।
Clean Code का मूल्य और सीमाएँ
- कई लोग इस किताब को शुरुआती करियर वाले डेवलपर्स के लिए संरचना देने वाला उपयोगी ढांचा मानते हैं।
- अन्य लोग तर्क देते हैं कि यह खराब या सीमित प्रथाएँ सिखाती है (“clean OOP code” केवल) और यह, यहाँ तक कि शुरुआती लोगों के लिए भी, सक्रिय रूप से हानिकारक है।
- आम शिकायत: यह कट्टर नियमों को बढ़ावा देती है (बहुत छोटे फ़ंक्शन, polymorphism, comments से दूरी) और एक उपदेशात्मक framing अपनाती है जो असहमति को “unprofessional” कहती है।
- कुछ लोग एक नए edition का उल्लेख करते हैं जो गलत व्याख्याओं को संबोधित करने के लिए बनाया गया है, लेकिन उसकी गुणवत्ता को अस्पष्ट बताया गया है।
Performance बनाम maintainability
- मुख्य बहस: “clean” abstractions (खासकर OO और polymorphism) अक्सर performance को नुकसान पहुँचाती हैं, लेकिन maintenance और extensibility को आसान बना सकती हैं।
- कई लोगों का तर्क है कि performance measurement से तय होनी चाहिए: सरल code लिखें, फिर hotspots optimize करें।
- अन्य लोग जवाब देते हैं कि कुछ styles (heavy runtime polymorphism, deep abstraction layers) किसी system को केवल hotspots में नहीं, बल्कि समग्र रूप से धीमा बना सकती हैं।
OOP, polymorphism, और alternatives
- कई लोग ध्यान दिलाते हैं कि classic example runtime polymorphism और vtables का उपयोग करता है, जो flat data और switches की तुलना में, खासकर tight loops में, धीमे माने जाते हैं।
- कुछ इस बात पर ज़ोर देते हैं कि modern compilers छोटे functions को अच्छी तरह inline कर लेते हैं; असली cost dynamic dispatch की होती है, “clean code” की नहीं।
- बताए गए alternatives: sum types के साथ exhaustive matches, procedural dispatch (switches या tables), static polymorphism, और नए languages में zero-cost abstractions।
Function size और structure
- function length rules पर तीखा मतभेद है।
- कुछ लोग clarity के लिए बहुत छोटे, single-purpose functions पसंद करते हैं; अन्य इस शैली को fragmented और follow करने में कठिन मानते हैं।
- लंबे लेकिन linear functions स्वीकार्य हो सकते हैं यदि वे “एक coherent चीज़” करते हों; कृत्रिम splitting readability को नुकसान पहुँचा सकती है।
Principles बनाम dogma
- कई commenters इस बात पर ज़ोर देते हैं कि DRY, SRP, और “clean code” जैसी principles low-level tools हैं जिनके trade-offs होते हैं, सार्वभौमिक laws नहीं।
- इनका अत्यधिक उपयोग dead coupling, fragmentation, low cohesion, और performance समस्याएँ पैदा करता है।
- सहमति का विषय: judgment का उपयोग करें; context (domain complexity, performance needs, team size, extensibility) design को drive करना चाहिए।
Article और examples की आलोचनाएँ
- कुछ लोगों को लगता है कि critique एक toy, non-performance-focused example पर हमला करता है और इसलिए strawman बन जाता है।
- दूसरे जवाब देते हैं कि example किताब से ही लिया गया था और concretely दिखाता है कि promoted style performance को कैसे खराब कर सकता है, जो एक वैध point है, भले ही मूल intent pedagogical रहा हो।
व्यापक ecosystem शिकायतें
- कई comments suggest करते हैं कि रोज़मर्रा के apps में worst performance issues OO patterns से कम और heavy stacks (जैसे Electron, desktop पर “web tech”) तथा network latency से ज़्यादा आते हैं, न कि केवल function size या polymorphism से।