پروگرامنگ میں خراب کوڈ: یہ کیا ہے، علامات اور کیسے صاف لکھیں

پروگرامنگ میں خراب کوڈ کیا ہے

خراب کوڈ کوڈ کی ایک موضوعی لیکن عام طور پر قبول شدہ خصوصیت ہے جو کم از کم معیار کے معیارات پر پورا نہیں اترتا۔ رابرٹ مارٹن نے اپنی کتاب کلین کوڈ (2008) میں خراب کوڈ کو ایسے کوڈ کے طور پر بیان کیا ہے جو “یہ سمجھنے میں رکاوٹ ڈالتا ہے کہ یہ کیا کرتا ہے”۔ خراب کوڈ نحوی طور پر درست اور کام کرنے والا بھی ہو سکتا ہے، لیکن اس کی دیکھ بھال ٹیم کے لیے ایک ڈراؤنا خواب بن جاتی ہے۔

خراب کوڈ کی اصطلاح خاص طور پر روسی بولنے والی کمیونٹی میں وسیع ہے۔ انگریزی میں زیادہ رسمی اصطلاحات استعمال ہوتی ہیں: اسپگیٹی کوڈ، ڈرٹی کوڈ، ٹیکنیکل ڈیٹ کوڈ۔ تاہم، “خراب کوڈ” کا جذباتی رنگ ڈویلپرز کے اس طرح کے کوڈ کے رویہ — چڑچڑاپن، نفرت اور پیشہ ورانہ توہین کا آمیزہ — کو زیادہ درست طریقے سے بیان کرتا ہے۔

McKinsey کے مطالعے (2023) کے مطابق، اعلیٰ سطح کے تکنیکی قرض والی کمپنیاں — اور خراب کوڈ اس کا اہم جزو ہے — نئی خصوصیات تیار کرنے میں 20–40% زیادہ وسائل خرچ کرتی ہیں۔ کوڈ کا معیار براہ راست کاروباری میٹرکس کو متاثر کرتا ہے، اور یہ کوئی استعارہ نہیں بلکہ ایک تصدیق شدہ حقیقت ہے۔

خراب کوڈ اور عام کوڈ کے درمیان حد

کوئی معروضی میٹرکس موجود نہیں ہے، لیکن عملی معیار ہیں: اگر کوئی ڈویلپر 20 لائنوں کے فنکشن کو سمجھنے میں 5 منٹ سے زیادہ صرف کرتا ہے — یہ خراب کوڈ ہے۔ اگر ایک لائن تبدیل کرنے سے تین غیر متعلقہ ماڈیول ٹوٹ جائیں — یہ خراب کوڈ ہے۔ اگر مکمل دوبارہ تحریر کے بغیر کوڈ کو ٹیسٹوں سے کور نہیں کیا جا سکتا — یہ خراب کوڈ ہے۔

خراب کوڈ کی اہم علامات

کاپی پیسٹ پروگرامنگ سب سے واضح اور آسانی سے پتہ لگانے والی علامات میں سے ایک ہے۔ جب کوڈ کا ایک ہی بلاک کم سے کم تبدیلیوں کے ساتھ متعدد جگہوں پر دہرایا جاتا ہے، تو یہ صرف خراب کوڈ نہیں ہے — یہ مستقبل کی خرابیوں کا ذریعہ ہے۔ ایک جگہ درست کرنا اور دوسری جگہ چھوڑ دینا ایک عام صورت حال ہے۔

بے معنی متغیر نام ایک کلاسک ہے۔ `a`، `b`، `x`، `data`، `temp`، `tmp`، `result`، `list`، `obj` جیسے ناموں والے متغیر اپنے مقصد کے بارے میں کوئی معلومات نہیں رکھتے۔ کوڈ پڑھنے والے کو یہ سمجھنے کے لیے پورے فنکشن کا تجزیہ کرنا پڑتا ہے کہ متغیر میں کیا ہے۔ رابرٹ مارٹن اسے “نام میں جھوٹ” کہتے ہیں — نام معلومات کا وعدہ کرتا ہے لیکن دیتا نہیں ہے۔

گہری نیسٹنگ — جب شرائط، لوپس اور خرابی کا انتظام 5+ انڈینٹیشن سطحوں کا ڈھانچہ بناتے ہیں۔ اس طرح کے کوڈ کو افقی اسکرولنگ یا تمام سطحوں کی ذہنی ٹریکنگ کے بغیر پڑھنا ناممکن ہے۔ یہ خرابیوں کا براہ راست راستہ ہے: منطقی آپریٹرز آسانی سے الجھ سکتے ہیں اور بند ہونے والے بریکٹ چھوٹ سکتے ہیں۔

پوشیدہ علامات

مردہ کوڈ (dead code) — فنکشنز، متغیرات، کلاسز جو کہیں استعمال نہیں ہوتے۔ یہ کوڈ کا حجم بڑھاتا ہے، ڈویلپر کو مشغول کرتا ہے، اور سسٹم کی صلاحیتوں کے بارے میں غلط تاثر پیدا کرتا ہے۔ جادوئی اعداد — سیاق و سباق کے بغیر اعداد۔ God کلاسز — کلاسز جو ایک ساتھ سب کچھ کرتی ہیں، واحد ذمہ داری کے اصول (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 نہ لکھیں۔ اگر لوپ اسٹریم سے آسان ہے — لوپ استعمال کریں۔ اگر ایک عام فنکشن ڈیکوریٹر سے زیادہ واضح ہے — فنکشن لکھیں۔ سادگی دیکھ بھال کے قابل کوڈ کا بنیادی معیار ہے۔

بوائے اسکاؤٹ اصول — “کوڈ کو اس سے بہتر چھوڑو جیسا تم نے پایا۔” ہر ترمیم کے ساتھ چھوٹی بہتری بھی آہستہ آہستہ خراب کوڈ کو اچھے کوڈ میں بدل دیتی ہے۔ ایک متغیر کا نام تبدیل کریں، ایک بڑے فنکشن کو تقسیم کریں، ایک ٹیسٹ شامل کریں — کوئی بھی بہتری اہم ہے۔

// خراب کوڈ — کاپی پیسٹ، جادوئی اعداد، ناقص نام
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 اصولوں کی تعمیل چیک کرنے کے لیے