यह code के lifespan और blast radius पर निर्भर करता है। ऐसे code के लिए clean code भरपूर फायदा देता है जो जीवित रहता है और बदलता है; throwaway, prototype, या कभी-कभार छुए जाने वाले code के लिए "good enough" सही चुनाव है। कौशल यह है कि आप अपने निवेश को परिस्थिति के अनुसार मिलाएँ — लापरवाही और gold-plating दोनों से बचते हुए।
Code quality एक है, और किसी भी निवेश की तरह इसका return समय और exposure पर निर्भर करता है। पूछने योग्य दो सवाल:
| Failure | कैसा दिखता है | कीमत |
|---|---|---|
| लापरवाही | ऐसे code में गंदगी भेजना जो जीवित रहेगा | भविष्य के बदलाव धीमे, bugs, क्षरण |
| Gold-plating | ऐसे code की over-engineering जो मायने नहीं रखेगा | बर्बाद समय, premature abstraction |
दोनों असली बर्बादी हैं। "Good enough" एक सोच-समझकर, संदर्भ-आधारित चुनाव है — लापरवाही का बहाना नहीं, और हमेशा के लिए चमकाने का लाइसेंस भी नहीं।
यह सवाल उन engineers को अलग करता है जो quality को dogmatically लागू करते हैं उनसे जो इसे economically लागू करते हैं। Clean code को एक धर्म की तरह मानना throwaways पर प्रयास बर्बाद करता है; इसे optional मानना उन systems को सड़ा देता है जिन पर आप निर्भर हैं। Senior judgment यह जानना है कि आप किस प्रकार का code पकड़े हुए हैं और उसी के अनुसार निवेश करना — और उस tradeoff को समझा पाना बिल्कुल वही व्यावहारिक सोच है जो teams देखना चाहती हैं।