Debugging: اسے خود تلاش کریں

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

غلطی کے پیغام کو شور کی طرح نہیں، ثبوت کی طرح پڑھیں

Stack traces کو غالباً نظر انداز کیا جاتا ہے کیونکہ وہ خطرناک نظر آتے ہیں۔ لیکن وہ عام طور پر آپ کو بالکل بتا رہے ہوتے ہیں کہ کہاں اور کیوں کوئی چیز ٹوٹی ہے۔ اگر آپ کو Python میں TypeError: 'NoneType' object is not subscriptable ملتا ہے، تو یہ بے معنی الفاظ نہیں ہیں — اس کا مطلب ہے کہ ایک متغیر جس کے پاس لسٹ یا dict ہونی چاہیے تھی دراصل None ہے۔ لائن نمبر آپ کو بتاتا ہے کہ یہ کہاں ہے۔ آپ کا کام اس لائن سے پیچھے کی طرف جانا ہے اور یہ تلاش کرنا ہے کہ قیمت کہاں سیٹ ہونی چاہیے تھی لیکن نہیں ہوئی۔

آن لائن کچھ بھی تلاش کرنے سے پہلے یہ کریں: traceback کی آخری لائن پہلے پڑھیں، پھر اوپر کی طرف جائیں۔ آخری لائن عام طور پر اصل exception کا نام بتاتی ہے۔ اس کے اوپر والی لائنیں call chain دکھاتی ہیں جو آپ کو وہاں لے گئی۔

اسے مقصد سے دہرایا جائے

اگر ایک bug صرف کبھی کبھار نظر آتا ہے، تو آپ اسے ابھی سمجھتے نہیں۔ code کو چھونے سے پہلے، اسے قابلِ اعتماد طریقے سے ہونے کی کوشش کریں۔ ایک وقت میں ایک input بدلیں۔ کیا یہ خالی لسٹ کے ساتھ ناکام ہوتا ہے لیکن مکمل کے ساتھ نہیں؟ کیا یہ صرف ایک function کی دوسری کال پر ناکام ہوتا ہے، پہلی پر نہیں؟ ایک bug جو آپ command پر دہرا سکتے ہوں وہ 80% حل شدہ ہے، کیونکہ اب آپ یہ ٹیسٹ کر سکتے ہیں کہ fix واقعی کام کرتی ہے یا نہیں۔

مسئلہ کو آدھا کریں، پھر دوبارہ آدھا کریں

Binary search صرف sorted arrays کے لیے نہیں ہے — یہ لمبے function یا pipeline میں ٹوٹے ہوئے code کو تلاش کرنے کا تیز ترین طریقہ ہے۔ اپنی منطق کے دوسرے نصف کو comment کریں یا bypass کریں اور چیک کریں کہ پہلا نصف ابھی بھی bug پیدا کرتا ہے۔ اگر ہاں، تو مسئلہ پہلے نصف میں ہے۔ اگر نہیں، تو دوسرے میں ہے۔ دوبارہ کریں۔ یہ 200 لائن کے script میں اتنی ہی اچھی طرح کام کرتا ہے جتنا multi-stage data pipeline میں جہاں آپ print() یا df.head() کے ساتھ ہر مرحلے پر outputs چیک کر رہے ہوں۔

یہ بے ترتیب طریقے سے لائنیں بدلنے اور دوبارہ چلانے سے بہتر ہے، جو زیادہ تر لوگ دباؤ میں کرتے ہیں اور یہ بہت زیادہ وقت ضائع کرتا ہے۔

جب print() کام کرنا بند کرے تو debugger استعمال کریں

print() statements سادہ cases کے لیے ٹھیک ہیں، لیکن جب آپ متعدد function calls میں state کا پیچھا کر رہے ہوں، ایک اصل debugger حقیقی وقت بچاتا ہے۔ Python میں، شک کی لائن سے پہلے import pdb; pdb.set_trace() ڈالیں، script چلائیں، اور آپ کو ایک live prompt ملتا ہے جہاں آپ variables کو دیکھ سکتے ہیں، n کے ساتھ لائن دراز چل سکتے ہیں، اور s کے ساتھ function calls میں جا سکتے ہیں۔ VS Code کا built-in debugger وہی کام کرتا ہے breakpoints کے ساتھ جو آپ type کرنے کی بجائے click کرتے ہیں۔ کسی بھی طریقے سے، مقصد ایک جیسا ہے: اپنے program کی اصل state دیکھیں بجائے یہ سوچنے کے کہ یہ شاید کیا ہے۔

اسے اپنے باقی project سے الگ کریں

اگر ایک bug بڑے codebase کے اندر ہوتا ہے، تو اسے بڑے codebase کے اندر debug نہ کریں۔ متعلقہ function کو ایک نئی file میں copy کریں نقلی، کم سے کم input کے ساتھ جو ایک جیسی ناکامی کو trigger کرے۔ اگر bug غائب ہو جاتا ہے، تو گرد و نواح کے بارے میں کچھ — ایک global variable، ایک import، stale state — اصل سبب ہے، اور آپ نے ابھی ہی کچھ اہم سیکھا ہے۔ اگر bug الگ تھلگ رہتا ہے، تو آپ کے پاس اب ایک چھوٹا، قابلِ اشتراک، قابلِ ٹیسٹ case ہے، اور آپ اصل fix کے قریب ہیں۔

اپنی قیاس آرائیوں کو یادداشت کے خلاف نہیں، حقیقت کے خلاف چیک کریں

debugging کا بہت بڑا حصہ بغیر سوال کی گئی قیاس آرائیوں میں چلا جاتا ہے: