صاف کوڈ کیسے لکھیں۔

اپنے کوڈ کو صاف ستھرا اور خوبصورت بنانا ڈیڈ لائن کو پورا کرنے کا ایک بہترین طریقہ ہے۔ رابرٹ مارٹن نے اپنے ایک بے تکے بیان کے ساتھ سر پر کیل مارا: "کوڈ کے معیار کا واحد صحیح پیمانہ What-The-F**ks/Minute یونٹ ہے۔ ." "اصل میں)۔ مجھے اس کا مطلب بتانے دو۔ جب بھی میں کوڈ کا جائزہ لیتا ہوں، میرا دماغ تین میں سے ایک جذبات سے گزرتا ہے:

• "WTF؟! کیا مصیبت ہے؟!" (ناراضگی سے) - یہ نہیں ہے... سب کچھ بہت برا ہے....
• "WTF؟! کیا مصیبت ہے؟!" (تعریف کے ساتھ) - ہمم، ایک ہوشیار آدمی نے یہ کیا!
• "WTF؟! کیا مصیبت ہے؟!" (جلن کے ساتھ) - کسی قسم کی الجھن، ہم کیا بات کر رہے ہیں؟!

تو سب سے اہم کیا ہے اور جب ہم کچھ کوڈ دیکھتے ہیں تو ہم بالکل کیا اندازہ کرتے ہیں؟ یہ ہے: اس کی پاکیزگی اور خوبصورتی۔ صاف اور خوبصورت کوڈ لکھنے کی صلاحیت ایک اعلیٰ پیشہ ور ڈویلپر کا اشارہ ہے۔ اس ہنر کی تربیت دو اجزاء پر مبنی ہے - علم اور کام۔ علم آپ کو نمونوں، اصولوں، طریقوں، heuristics سکھاتا ہے۔ آپ کو پیشہ ورانہ طور پر بڑھنے کے لئے ان کی ضرورت ہے۔ صرف آپ کو مسلسل مشق اور محنت کے ذریعے اس علم کو سپنج کی طرح جذب کرنا چاہیے۔ مختصر میں، صاف کوڈ لکھنا آسان نہیں ہے۔ یہ مشکل، محنتی کام ہے، اور آپ کو اس پر سخت محنت کرنی پڑے گی۔ آزمائش اور غلطی کے ذریعے، آپ انہی اقدامات کو بار بار دہراتے ہوئے بہتری لائیں گے جب تک کہ آپ کو مطلوبہ حل نہ مل جائے۔ بس کوئی آسان طریقہ نہیں ہے۔ کلین کوڈ لکھنے کا طریقہ سیکھنے میں آپ کی مدد کے لیے ذیل میں کچھ نکات ہیں۔

نام میں کیا رکھا ہے

کینڈرک لامر (امریکی ہپ ہاپ آرٹسٹ - ایڈیٹر کا نوٹ) نے ایک بار درست طریقے سے نوٹ کیا: "اگر میں اصل کہانی سنانے جا رہا ہوں، تو مجھے اپنے نام سے شروع کرنا ہوگا۔" سافٹ ویئر ڈویلپمنٹ میں نام ہر جگہ ہیں۔ ہم فنکشنز، کلاسز، آرگیومنٹس، پیکجز، پروگرامز—ہر چیز کا نام دیتے ہیں۔ ہم سورس فائلوں اور حوالہ جاتی کتابوں اور اس سے جڑی ہر چیز کا نام دیتے ہیں۔ ہم چیزوں کو لامتناہی نام دیتے ہیں، اور یہ کلین کوڈ بنانے کی سمت کام کرنے کا ایک اہم حصہ بن جاتا ہے۔ آپ جو نام دیتے ہیں اس سے نیت کی عکاسی ہوتی ہے۔ اچھا نام تلاش کرنا آسان نہیں ہے، اس میں وقت لگتا ہے، لیکن اس میں بہت وقت بھی بچ جاتا ہے جب آپ کو کوڈ سے نمٹنا پڑتا ہے اور صورتحال پیچیدہ ہو جاتی ہے۔ اس لیے اس عمل کے بارے میں محتاط رہیں اور اگر آپ کو کوئی اور مناسب چیز مل جائے تو بعد میں نام تبدیل کرنے سے نہ گھبرائیں۔ ہر کوئی جو آپ کے کوڈ سے نمٹتا ہے وہ آپ کا بہت مشکور ہوگا۔

"ایک فنکشن" - ایک چیز

لوئس ہنری سلیوان (امریکی عقلیت پسند اور ماڈرنسٹ ماہر تعمیرات) نے ایک بار مشہور کہا تھا: "فعل شکل کا تعین کرتا ہے ۔ " انہوں نے یہ بات گھروں کے فن تعمیر کے بارے میں کہی، لیکن اس سے جوہر نہیں بدلتا۔ ہر نظام کو کچھ ڈومین مخصوص زبان پر بنایا گیا ہے جسے پروگرامر درست طریقے سے بیان کرنے کے لیے تخلیق کرتے ہیں۔ افعال زبان کے فعل کے طور پر کام کرتے ہیں، اور طبقات اسم ہیں۔ اکثر اوقات، فنکشنز پروگرامنگ لینگویج کی تنظیم میں سب سے اہم ہوتے ہیں، اور انہیں صحیح طریقے سے لکھنا ہی اچھے کوڈ کی تخلیق کا نچوڑ ہے۔ معیاری افعال لکھنے کے لیے صرف دو سنہری اصول ہیں:

1. وہ چھوٹے ہونے چاہئیں
2. انہیں ایک کام، ایک کام، اور اسے اچھی طرح سے کرنا چاہیے۔

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

"تبصرے خراب کوڈ کے لیے نہیں بنتے"

امریکی ٹینس کھلاڑی اور پانچ بار ومبلڈن چیمپئن وینس ولیمز نے سر پر کیل ٹھونک دی جب اس نے کہا: "ہر کوئی اپنے تبصرے چھوڑتا ہے۔ اس طرح افواہیں سامنے آتی ہیں ۔ " تبصرے دو دھاری تلوار کی طرح ہوتے ہیں، اچھی طرح سے تبصرہ بہت مفید چیز ہے۔ دوسری طرف، فضول، فضول تبصروں کے علاوہ کوئی بھی چیز جگہ کو خراب نہیں کرتی۔ لیکن سب سے زیادہ نقصان دہ تبصرے وہ ہیں جو غلط معلومات اور جھوٹ پھیلاتے ہیں۔ مختصراً، تبصرے ایک قسم کی ضروری برائی ہیں۔ ہمیشہ نہیں، لیکن زیادہ تر حصے کے لیے۔ کیوں؟ یہ آسان ہے، تبصرہ جتنا پرانا ہوگا، اسے برقرار رکھنا اتنا ہی مشکل ہے، اور زیادہ تر پروگرامرز، جیسا کہ آپ جانتے ہیں، ہمیشہ کوڈ میں تبدیلی کے ساتھ تبصرے تبدیل نہیں کرتے ہیں۔ کوڈ حرکت کرتا ہے اور تیار ہوتا ہے۔ کوڈ کے حصوں کو آگے پیچھے منتقل کیا جاتا ہے، لیکن کوئی تبصرہ نہیں ہوتا ہے۔ اور یہ ایک مسئلہ بن جاتا ہے!

"کوڈ فارمیٹنگ ہمیشہ ایک ترجیح ہے"

یہ بات کسی اور نے نہیں بلکہ رابرٹ سی مارٹن (رابرٹ سیسل مارٹن) نے کہی، عرف انکل باب، ڈویلپر، سافٹ ویئر ڈویلپمنٹ پر بہت سی کتابوں کے مصنف، کنسلٹنٹ، ایجائل مینی فیسٹو کے شریک مصنف، وغیرہ۔ اور اس نے مزید کہا: "فارمیٹنگ کوڈ ایک قسم کا مواصلت ہے۔ اور مواصلات کسی بھی پیشہ ور ڈویلپر کے لئے اولین ترجیح ہے۔ مندرجہ بالا بیان کو کم نہیں سمجھا جانا چاہئے، کیونکہ یہ ایک بہترین ڈویلپر کی سب سے اہم خصوصیات میں سے ایک سے بات کرتا ہے. فارمیٹ شدہ کوڈ آپ کو اپنے دماغ کی گہرائی میں دیکھنے کی اجازت دیتا ہے۔ ہم لوگوں کو اپنی صفائی، تفصیل پر توجہ، اپنے خیالات کو منظم اور واضح طور پر ظاہر کرنے کی صلاحیت سے متاثر کرنا چاہتے ہیں۔ لیکن اگر، جب لوگ کوڈ کو دیکھتے ہیں، تو انہیں کسی قسم کی الجھن نظر آتی ہے، جو کہ وینیگریٹی کی یاد دلاتا ہے، جس کا نہ آغاز ہوتا ہے اور نہ ہی اختتام، یہ آپ کی کوششوں کی نفی کرتا ہے اور ڈویلپر کی ساکھ کو کم کرتا ہے۔ اس پر شک بھی نہ کرو! آپ سچائی سے بہت دور ہیں اگر آپ کو لگتا ہے کہ اس کاروبار میں بنیادی چیز یہ ہے کہ "کوڈ صرف کام کرتا ہے۔" آج آپ جو فعالیت بناتے ہیں وہ ممکنہ طور پر اگلی ریلیز میں تبدیل ہو جائے گی، لیکن کوڈ کی پڑھنے کی اہلیت میں کوئی تبدیلی نہیں آئے گی۔ کوڈ کا انداز اور اس کی اچھی پڑھنے کی اہلیت اس کوڈ کو لمبے عرصے تک برقرار رکھنا آسان بناتی ہے، یہاں تک کہ اصل کوڈ کو پہچانے جانے سے باہر تبدیل کرنے کے بعد بھی۔

پہلے "Try-catch-finally" بلاک بنائیں

جارج کینگوئیلہیم (سائنس کے مورخ، فلسفی) نے بجا طور پر کہا: "غلطیاں کرنا انسان کے لیے فطری ہے، لیکن غلطیوں پر اصرار کرنا شیطان کی طرف سے ہے ۔ " ٹربل شوٹنگ وہ کام ہے جو تمام پروگرامرز کرتے ہیں۔ غلط ڈیٹا ان پٹ میں داخل ہو سکتا ہے اور آلات ناکام ہو سکتے ہیں۔ اور بطور ڈویلپر، ہمیں یہ یقینی بنانا ہوگا کہ کوڈ وہی کرتا ہے جو اسے کرنا ہے۔ مسئلہ صرف غلطی سے نمٹنے کا نہیں ہے، بلکہ "صاف اور پڑھنے میں آسان" غلطی سے نمٹنے کا ہے۔ بہت سے پروگرام غلطی سے نمٹنے کے لیے موافق ہوتے ہیں۔ اگر آپ ایسا کرتے ہیں تو، ہر چیز ایسی افراتفری میں اتر جاتی ہے کہ مرکزی کوڈ کا مقصد اور منطق تباہ ہو جاتا ہے۔ یہ غلط ہے، ایسا نہیں ہونا چاہیے۔ کوڈ صاف اور قابل اعتماد ہونا چاہیے، اور غلطی سے نمٹنے کو بغیر کسی رکاوٹ کے اور قدرتی طور پر کوڈ میں بُنا جانا چاہیے۔ یہ ایک اعلی درجے کے پروگرامر کا اشارہ ہے۔ اور اس کو حاصل کرنے کے طریقوں میں سے ایک مناسب nesting اور ٹرائی کیچ بلاکس میں تمام غلطیوں کی کوریج ہے۔ یہ بلاکس آپ کے کوڈ کے دائرہ کار کی وضاحت کرتے ہیں۔ جب آپ ٹرائی-کیچ-آخر میں بلاک کے ٹرائی حصے میں کوڈ پر عمل کرتے ہیں، تو آپ یہ بتا رہے ہیں کہ عملدرآمد کسی بھی وقت اسقاط ہو سکتا ہے اور پھر کیچ میں دوبارہ شروع ہو سکتا ہے۔ لہذا، ہم تجویز کرتے ہیں کہ جب آپ کوڈ لکھیں تو آخر میں ٹرائی کیچ کے ساتھ شروع کریں۔ اس سے اس بات کا تعین کرنے میں مدد ملے گی کہ صارف کوڈ سے کیا توقع کر سکتا ہے، قطع نظر اس کے کہ کوشش کے دوران کوڈ میں کیا خرابی ہو۔

آئیے اس کا خلاصہ کرتے ہیں۔

ایک غیر معمولی جملہ مندرجہ بالا تمام کا خلاصہ کرنے میں ہماری مدد کرے گا۔ یہ کوڈ سینس یا "کامن کوڈ کا احساس" ہے، ایک قسم کا پروگرامر جو کامن سینس کے برابر ہے۔ رابرٹ مارٹن کے الفاظ میں: "صاف کوڈ لکھنے کے لیے بہت سی چھوٹی تکنیکوں کے منظم استعمال کی ضرورت ہوتی ہے، جو "صفائی" کے پیچیدہ اور کسی حد تک تکلیف دہ احساس کے نتیجے میں لاگو ہوتے ہیں۔ ان چھوٹی تکنیکوں کو اجتماعی طور پر کوڈ سینس کہا جاتا ہے ۔ " ہم میں سے کچھ کے پاس یہ "ساؤنڈ کوڈ سینس" شروع سے ہے، جبکہ دوسروں کو اسے مستقل مشق کے ذریعے تیار کرنا پڑتا ہے۔ یہ جبلت نہ صرف برے اور اچھے کوڈ کے درمیان فرق کو پہچاننے میں مدد کرتی ہے بلکہ برے کوڈ کو اچھے میں تبدیل کرنے کے لیے حکمت عملیوں کی تشکیل میں بھی مدد کرتی ہے۔ خراب کوڈ سب کچھ برباد کر دیتا ہے۔ علامتی طور پر بات کرتے ہوئے، اگر آپ کتے کی گندگی کے ساتھ انتہائی لذیذ کیک کو پالا دیتے ہیں، تو... اہ... شاید ہی کسی کو پسند آئے۔ کوڈ سینس پروگرامر کو کلین کوڈ بنانے کے اپنے مقصد کو حاصل کرنے کے لیے صحیح ٹولز استعمال کرنے میں مدد کرتا ہے۔ ایک پروگرامر جو سمجھتا ہے کہ کوڈ سینس کیا ہے وہ ایک فنکار ہے جو ایک خالی اسکرین پر آرٹ کا کام بنا سکتا ہے جسے کئی سالوں تک یاد رکھا جائے گا۔ جیسا کہ ہیرالڈ "ہال" ایبلسن، ایم آئی ٹی میں کمپیوٹر سائنس کے پروفیسر اور کریٹیو کامنز اور فری سافٹ ویئر فاؤنڈیشن کے بانی ڈائریکٹر، نے اس کا خلاصہ کیا: "پروگراموں کو پہلے لکھنے کی ضرورت ہے تاکہ لوگ انہیں پڑھ سکیں، اور پھر تاکہ وہ تیار ہو سکیں۔ پھانسی دی گئی۔ کار" ۔ آپ اس موضوع پر کیا پڑھ سکتے ہیں: "Agile Software Craftsmanship کی ایک ہینڈ بک" - رابرٹ مارٹن۔ "ایک ہینڈ بک آف چست اندازے" - مائیک کوہن مصنف کے بارے میں: روی شنکر راجن ممبئی (انڈیا) سے گلوبل آئی ٹی پروگرام مینیجر ہیں۔ مشہور بلاگر، ہائیکو شاعر، آرکیالوجی اور تاریخ کے شوقین۔ آپ اس کے ساتھ ٹویٹر ، میڈیم ، لنکڈ ان پر رابطہ کر سکتے ہیں۔