प्रोग्रामिंग में गंदा कोड: यह क्या है, संकेत और कैसे साफ लिखें

प्रोग्रामिंग में गंदा कोड क्या है

गंदा कोड कोड की एक व्यक्तिपरक लेकिन आम तौर पर स्वीकृत विशेषता है जो न्यूनतम गुणवत्ता मानकों को पूरा नहीं करता है। रॉबर्ट मार्टिन ने अपनी पुस्तक क्लीन कोड (2008) में खराब कोड को ऐसे कोड के रूप में परिभाषित किया है जो “yeh samajhne mein badha banata hai ki yah kya karta hai”। गंदा कोड वाक्य रचना की दृष्टि से सही और काम करने वाला भी हो सकता है, लेकिन इसका रखरखाव टीम के लिए बुरा सपना बन जाता है।

गंदा कोड शब्द विशेष रूप से रूसी भाषी समुदाय में व्यापक है। अंग्रेजी में अधिक औपचारिक शब्द उपयोग किए जाते हैं: स्पेगेटी कोड, गंदा कोड, तकनीकी ऋण कोड। हालांकि, “गंदा कोड” का भावनात्मक रंग डेवलपर्स के ऐसे कोड के प्रति दृष्टिकोण को अधिक सटीक रूप से व्यक्त करता है — जलन, घृणा और पेशेवर अपमान का मिश्रण।

McKinsey अध्ययन (2023) के अनुसार, उच्च स्तर के तकनीकी ऋण वाली कंपनियाँ — और गंदा कोड इसका मुख्य घटक है — नई सुविधाओं को विकसित करने पर 20–40% अधिक संसाधन खर्च करती हैं। कोड की गुणवत्ता सीधे व्यावसायिक मीट्रिक को प्रभावित करती है, और यह कोई रूपक नहीं बल्कि एक पुष्ट तथ्य है।

गंदे कोड और सामान्य कोड के बीच की सीमा

कोई वस्तुनिष्ठ मीट्रिक मौजूद नहीं है, लेकिन व्यावहारिक मानदंड हैं: यदि कोई डेवलपर 20 पंक्तियों के फ़ंक्शन को समझने में 5 मिनट से अधिक खर्च करता है — यह गंदा कोड है। यदि एक पंक्ति बदलने से तीन असंबंधित मॉड्यूल टूट जाते हैं — यह गंदा कोड है। यदि पूर्ण पुनर्लेखन के बिना कोड को परीक्षणों द्वारा कवर नहीं किया जा सकता — यह गंदा कोड है।

गंदे कोड के मुख्य संकेत

कॉपी-पेस्ट प्रोग्रामिंग सबसे स्पष्ट और आसानी से पता लगाने योग्य संकेतों में से एक है। जब कोड का एक ही ब्लॉक न्यूनतम बदलावों के साथ कई स्थानों पर दोहराया जाता है, तो यह सिर्फ गंदा कोड नहीं है — यह भविष्य की बग्स का स्रोत है। एक जगह ठीक करना और दूसरी जगह छोड़ देना एक सामान्य स्थिति है।

अर्थहीन चर नाम एक क्लासिक है। `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` जैसे नामों वाले चर अपने उद्देश्य के बारे में कोई जानकारी नहीं देते हैं। कोड पाठक को यह समझने के लिए पूरे फ़ंक्शन का विश्लेषण करना पड़ता है कि चर में क्या है। रॉबर्ट मार्टिन इसे “नाम में झूठ” कहते हैं — नाम जानकारी का वादा करता है लेकिन देता नहीं है।

गहरी नेस्टिंग — जब स्थितियाँ, लूप और त्रुटि प्रबंधन 5+ इंडेंटेशन स्तरों वाली संरचना बनाते हैं। ऐसे कोड को क्षैतिज स्क्रॉलिंग या सभी स्तरों के मानसिक ट्रैकिंग के बिना पढ़ना असंभव है। यह त्रुटियों का सीधा रास्ता है: तार्किक ऑपरेटर आसानी से भ्रमित हो सकते हैं और बंद करने वाले ब्रैकेट छूट सकते हैं।

छिपे हुए संकेत

मृत कोड (dead code) — फ़ंक्शन, चर, वर्ग जो कहीं उपयोग नहीं किए जाते। यह कोड की मात्रा बढ़ाता है, डेवलपर को विचलित करता है, और सिस्टम की क्षमताओं के बारे में गलत धारणा बनाता है। जादुई संख्याएँ — बिना संदर्भ की संख्याएँ। गॉड वर्ग — वर्ग जो एक साथ सब कुछ करते हैं, एकल जिम्मेदारी सिद्धांत (SOLID: S) का उल्लंघन करते हैं।

गंदा कोड क्यों दिखाई देता है

समय की कमी सबसे आम कारण है। जब समय सीमाएँ निकट होती हैं, डेवलपर्स गति के लिए गुणवत्ता का त्याग करते हैं। सामरिक रूप से, यह उचित हो सकता है, लेकिन रणनीतिक रूप से — यह तकनीकी ऋण संचित कर रहा है। समस्या यह है कि “अस्थायी” गंदा कोड शायद ही कभी ठीक करने के लिए वापस आता है।

कोड रिव्यू की कमी दूसरा सबसे महत्वपूर्ण कारण है। जब कोड सहकर्मी समीक्षा के बिना अकेले लिखा जाता है, तो खराब पैटर्न गहरे जड़ जमा लेते हैं और गुणा करते हैं। कोड रिव्यू सिर्फ गुणवत्ता नियंत्रण नहीं बल्कि टीम के भीतर ज्ञान हस्तांतरण भी है। बिना समीक्षा वाली परियोजनाएँ अनिवार्य रूप से गंदे कोड की ओर बढ़ती हैं।

डेवलपर की कम योग्यता या मेंटरशिप की कमी। बिना पर्यवेक्षण के छोड़े गए जूनियर डेवलपर्स स्वाभाविक रूप से गंदा कोड लिखते हैं — यह सीखने की प्रक्रिया का हिस्सा है। समस्या तब उत्पन्न होती है जब यह कोड बिना समीक्षा और रीफैक्टरिंग के उत्पादन में चला जाता है।

सांस्कृतिक कारक

उन टीमों में जहाँ “यह काम करता है, बस ठीक है” आदर्श वाक्य है, गंदा कोड पनपता है। कोडिंग मानकों, परीक्षण आवश्यकताओं और समीक्षा प्रक्रियाओं की अनुपस्थिति एक ऐसा वातावरण बनाती है जहाँ कोड की गुणवत्ता किसी की चिंता नहीं है। ऐसी परियोजनाएँ जल्दी से “लीगेसी‍" बन जाती हैं — कोड जिसे छूने से हर कोई डरता है।

प्रोजेक्ट के लिए गंदे कोड के परिणाम

गंदे कोड का मुख्य परिणाम विकास की धीमी गति है। खराब कोड का विरोधाभास यह है कि यह पहला संस्करण जल्दी लिखने की अनुमति देता है, लेकिन प्रत्येक बाद का सुधार अधिक समय लेता है। कोड गुणवत्ता बनाम विकास गति का ग्राफ घातांकीय है — एक निश्चित सीमा के बाद, नई सुविधाएँ जोड़ना व्यावहारिक रूप से असंभव हो जाता है।

कर्मचारी टर्नओवर एक अप्रत्यक्ष लेकिन गंभीर परिणाम है। डेवलपर्स, विशेष रूप से अनुभवी लोग, गंदे कोड के साथ काम नहीं करना चाहते। Stack Overflow डेवलपर सर्वेक्षण 2024 के अनुसार, 47% डेवलपर्स कार्यस्थल चुनते समय कोडबेस गुणवत्ता को मुख्य कारकों में से एक मानते हैं। खराब कोड वाली परियोजनाएँ अपने सर्वश्रेष्ठ कर्मचारियों को खो देती हैं।

सुरक्षा गंदे कोड का एक और शिकार है। खराब लिखे कोड में अधिक कमज़ोरियाँ होती हैं: अनहैंडल्ड अपवाद, SQL इंजेक्शन, XSS, मेमोरी लीक। यूनिट परीक्षणों और कोड रिव्यू के साथ गुणवत्ता कोड उत्पादन से पहले इनमें से अधिकांश समस्याओं को पकड़ लेता है।

तकनीकी ऋण एक मीट्रिक के रूप में

SonarQube और इसी तरह के उपकरण व्यक्ति-घंटे या दिनों में तकनीकी ऋण का अनुमान लगा सकते हैं। उदाहरण के लिए, कॉपी-पेस्ट के बारे में 500 चेतावनियाँ, जादुई संख्याओं के बारे में 200, और गहरी नेस्टिंग के बारे में 50, तकनीकी ऋण के 30 दिनों का अनुमान देती हैं। रीफैक्टरिंग को उचित ठहराने के लिए इन आंकड़ों को प्रबंधन को दिखाया जा सकता है और दिखाया जाना चाहिए।

गंदे कोड के बजाय साफ कोड कैसे लिखें

DRY (Don’t Repeat Yourself) सिद्धांत पहली चीज़ है जिसे लागू करना चाहिए। तर्क का प्रत्येक टुकड़ा एक ही स्थान पर मौजूद होना चाहिए। कॉपी-पेस्ट के बजाय — दोहराए जाने वाले कोड को एक अलग फ़ंक्शन, वर्ग या मॉड्यूल में निकालें। जादुई संख्याओं के बजाय — नामित स्थिरांक। लंबे फ़ंक्शन के बजाय — कई छोटे।

KISS (Keep It Simple, Stupid) सिद्धांत अत्यधिक जटिलता से बचाता है। यदि किसी कार्य को 10 पंक्तियों में हल किया जा सकता है — 50 मत लिखें। यदि लूप स्ट्रीम से सरल है — लूप का उपयोग करें। यदि एक सामान्य फ़ंक्शन डेकोरेटर से स्पष्ट है — फ़ंक्शन लिखें। सादगी रखरखाव योग्य कोड का मुख्य गुण है।

Boy Scout नियम — “कोड को उससे बेहतर छोड़ो जैसा तुमने पाया।” प्रत्येक संपादन के साथ छोटे सुधार भी धीरे-धीरे गंदे कोड को अच्छे कोड में बदल देते हैं। एक चर का नाम बदलें, एक बड़े फ़ंक्शन को विभाजित करें, एक परीक्षण जोड़ें — कोई भी सुधार मायने रखता है।

// गंदा कोड — कॉपी-पेस्ट, जादुई संख्याएँ, खराब नाम
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// साफ कोड — स्पष्ट नाम, DRY, स्थिरांक
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

रीफैक्टरिंग के उदाहरण

आइए Python में एक विशिष्ट उदाहरण देखें। फ़ंक्शन ऑर्डर प्रोसेस करता है लेकिन खराब तरीके से: 80 पंक्तियाँ, गहरी नेस्टिंग, जादुई संख्याएँ, दोहराव। रीफैक्टरिंग के बाद, कोड पढ़ने योग्य, परीक्षण योग्य और रखरखाव योग्य हो जाता है।

# गंदा कोड — एक ही फ़ंक्शन सब कुछ करता है
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# साफ कोड — निकाले गए फ़ंक्शन और स्थिरांक
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

फ़ंक्शन के लिए तीन पंक्तियों का नियम

एक अच्छा फ़ंक्शन एक काम करता है और उसे अच्छी तरह करता है। यदि कोई फ़ंक्शन तीन अलग-अलग काम करता है — उसे विभाजित करें। यदि किसी फ़ंक्शन में 20 से अधिक पंक्तियाँ हैं — संभवतः इसे विभाजित किया जा सकता है। यदि किसी फ़ंक्शन में दो से अधिक इंडेंटेशन स्तर हैं — उसे रीफैक्टरिंग की आवश्यकता है।

कोड रिव्यू उपकरण

स्थिर कोड विश्लेषक गंदे कोड के खिलाफ रक्षा की पहली पंक्ति हैं। ESLint (JavaScript), Pylint (Python), SonarQube (बहु-भाषा), Checkstyle (Java) स्वचालित रूप से कॉपी-पेस्ट, जादुई संख्याएँ, खाली कैच ब्लॉक, अत्यधिक लंबे फ़ंक्शन और सैकड़ों अन्य एंटीपैटर्न का पता लगाते हैं।

कोड शैली और फ़ॉर्मेटर सुरक्षा का दूसरा स्तर हैं। Prettier, Black, gofmt स्वचालित रूप से कोड को फ़ॉर्मेट करते हैं, स्थानों, इंडेंटेशन और ब्रैकेट की समस्याओं को समाप्त करते हैं। टीम में एक समान शैली कोड को इस बात की परवाह किए बिना पढ़ने योग्य बनाती है कि इसे किसने लिखा। फ़ॉर्मेटिंग विवादों को स्वचालित किया जाना चाहिए।

कोड रिव्यू तीसरा और सबसे महत्वपूर्ण स्तर है। कोई विश्लेषक उस मानव को प्रतिस्थापित नहीं कर सकता जो नोटिस करता है कि समाधान वास्तुकला गलत है या डेवलपर ने गलत दृष्टिकोण चुना। प्रभावी समीक्षा में समय लगता है, लेकिन यह गंदे कोड की मात्रा को काफी कम करके अपना लाभ देता है।

• ESLint — JavaScript और TypeScript के लिए जटिलता, max-lines, max-nested-callbacks नियमों के साथ
• Pylint — Python के लिए कोड मीट्रिक और गुणवत्ता स्कोर ( -10 से 10) के साथ
• SonarQube — समय के साथ तकनीकी ऋण को ट्रैक करने के लिए
• CodeClimate — प्रत्येक फ़ाइल की रखरखाव क्षमता सूचकांक का मूल्यांकन करने के लिए
• Better Code Hub — साफ कोड के 10 सिद्धांतों के अनुपालन की जाँच के लिए