اگر ہینڈ رائٹنگ کوڈ کا خیال احمقانہ لگتا ہے، تو یہ جان کر آپ کو حیرت ہو سکتی ہے کہ یہ ناگزیر ہے۔ اگر آپ کو یقین نہیں ہے تو، آپ نے آخری ملازمت کے انٹرویو کے بارے میں سوچیں، اور یاد رکھیں کہ انٹرویو کے کمرے میں کس طرح کوئی کمپیوٹر نہیں تھا - صرف آپ کے انٹرویو لینے والے، کاغذ کی ایک خالی شیٹ، اور ایک نیلے بال پوائنٹ قلم۔
آپ کے درمیان کے طلباء کے لیے، یہ اور بھی بڑی بات ہے کیونکہ آپ کے درجات کوڈ کی لائنوں کے مطابق آپ نے حکمت عملی کے ساتھ اپنی جوابی شیٹ میں دستیاب جگہ کو نچوڑ لیا تھا۔
اور صرف یہی نہیں، تجربہ کار پروگرامرز آپ کو A4 شیٹس کے بنڈل کی طرف اشارہ کر سکتے ہیں جسے انہوں نے آفس کاپی مشین سے ہٹا دیا تھا تاکہ وہ خاص طور پر پیچیدہ الگورتھم کو لکھ سکیں جس پر وہ کام کر رہے تھے۔
اس لیے چاہے آپ امتحان کے طالب علم ہوں، ممکنہ ملازمت کے انٹرویو لینے والے ہوں، یا کوئی ایسا شخص جو اپنے پروگرامنگ کے آخری مراحل کو حل کرنا چاہتا ہو، مجھے امید ہے کہ جب آپ کاغذ کو کوڈ کرنے کے لیے اپنا قلم ڈالیں گے تو یہ مضمون آپ کی مدد کرے گا۔
اگرچہ میں تحریری کوڈ کے ینالاگ پہلو پر توجہ دوں گا، لیکن آپ ان اقدامات کو کسی بھی شکل یا زبان میں کوڈنگ کے لیے لاگو کر سکتے ہیں۔ لہذا اس کو بھی ایک عام کوڈنگ گائیڈ لائن کی طرح سمجھیں جو خاص طور پر میرے لیے کام کرتا ہے لیکن آپ کے کام میں آپ کے لیے بہت مفید بھی ہو سکتا ہے۔
یہ کیوں لکھیں؟
اس سے پہلے کہ ہم شروع کریں، یہ سمجھنا ضروری ہے کہ کوئی بھی آپ سے پروڈکشن کے لیے تیار کوڈ کو نوٹ بک میں لکھنے کی توقع نہیں کرتا ہے۔ ایسا نہیں ہے کہ آپ اسے کوڈ ایڈیٹر میں ڈالیں اور اسے بغیر کسی غلطی کے مرتب کریں۔ اگر کامل کوڈ تیار کرنا مقصد تھا، تو آپ کو انٹرویو کے کمروں اور امتحانی ہالوں میں کمپیوٹر کے سامنے بٹھایا جائے گا۔
ہینڈ رائٹنگ کوڈ کا مقصد پیشگی منطق کے ذریعے کام کرنا ہے۔ ڈیزائن میں جلد از جلد "براؤزر میں داخل ہونے" کی خواہش ہے، لیکن ہاتھ سے ڈیزائن کی خاکہ نگاری میں روایتی حکمت ہے۔ کم مخلص میڈیم فوری تجربہ اور سستی غلطیوں کی حوصلہ افزائی کرتا ہے۔
یہی بات کوڈ کے معاملے میں بھی ہو سکتی ہے، بنیادی طور پر جب نحو اور سیمنٹکس پر کام کریں۔ اس نے کہا، صحیح نحو اور سیمنٹکس حاصل کرنا ہے۔ ہمیشہ ایک پلس پوائنٹ، اگرچہ ہینڈ رائٹنگ کی پوری مشق کا واحد فوکس نہیں ہے۔
آئیے دیکھتے ہیں کہ جب ہینڈ رائٹنگ کوڈ کی بات آتی ہے تو ہم کہاں سے شروع کر سکتے ہیں۔
اپنا سوال جانیں۔
کالج میں اپنے آخری سال کے دوران، میں صحت کی وجوہات کی بناء پر انٹرن شپ یا کیمپس انٹرویوز میں شرکت نہیں کر سکا۔ نتیجے کے طور پر، میرا پہلا ملازمت کا انٹرویو بہت زیادہ داؤ پر لگا ہوا تھا۔
اب جب میں نے پیچھے مڑ کر دیکھا تو انٹرویو کافی آسان تھا۔ لیکن اس سے پہلے کبھی بھی شرکت نہ کرنے کی وجہ سے میں بے فکر تھا۔ سب سے پہلی چیز جو انٹرویو لینے والوں نے پروگرامنگ کے بارے میں پوچھی وہ یہ تھی کہ کیا میں ستاروں سے بنا ایک الٹی مثلث نکال سکتا ہوں۔ جیسا کہ میں نے کہا، یہ آسان تھا - کچھ نہیں a for لوپ نہیں سنبھال سکتا، ٹھیک ہے؟ لیکن جیسا کہ میں نے کہا، میری پریشانی چھت کے ذریعے بھی تھی۔
میں نے ایک گہرا سانس لیا، اپنی ہتھیلی کو کاغذ کی خالی چادر سے دبایا جو انہوں نے میرے لیے بچھا رکھا تھا، اسے میز پر اپنی طرف جتنی آہستہ ہو سکے پھسلایا (یقیناً وقت خریدنے کا)، قلم پر کلک کیا، اور پھر میں نے کچھ کیا۔ صحیح
میں نے سب سے پہلے ستاروں سے بنا ایک الٹا مثلث کھینچا۔ اس طرح میں نے ان کے سوال کا جواب دینے کے لیے اپنے پاؤں زمین پر رکھے۔
میں نے دیکھا ہے کہ بصورت دیگر شاندار ڈویلپرز کو کچھ غلط ہو جاتا ہے صرف اس وجہ سے کہ وہ کبھی بھی پوری طرح سے نہیں سمجھتے کہ وہ کیا حل کر رہے ہیں۔
ہم جن سوالات کے ساتھ کام کرتے ہیں وہ سوالات کی طرح نہیں ہیں جو طبیعیات دان یا ریاضی دان حل کرتے ہیں۔ وہ پیرامیٹرز کا ایک سیٹ حاصل کرتے ہیں اور گمشدہ کو تلاش کرتے ہیں۔ ہمارے سوالات بھی ہمارے نتائج ہیں۔ ہمیں پہلے ہی بتا دیا گیا ہے کہ ہمارے نتائج کیا ہیں — ہمیں ان تک پہنچنے کا طریقہ معلوم کرنا ہے۔ اس لیے سوال کو اچھی طرح جاننا ضروری ہے کیونکہ آپ نتیجہ دیکھیں گے۔
آپ جس چیز کو آؤٹ پٹ کرنا چاہتے ہیں اسے لکھنا یا ڈرائنگ کرنا اپنی کوڈنگ شروع کرنے کے بہترین طریقوں میں سے ایک ہے۔ میں سمجھتا ہوں کہ ہماری تیز رفتار صنعت میں، توقع یہ ہے کہ ہمیں "ہیلو ورلڈ" ڈیمو چلا کر پروگرامنگ میں کودنا پڑے گا۔ اور یہ بہت اچھا ہے کہ اپنے آپ کو ایک غیر مانوس ترکیب سے آشنا کریں اور کچھ نیا کرنے کی کوشش کرنے کے بارے میں اپنی بے چینی کو دور کریں۔
لیکن جب کوئی آپ سے کوئی سوال پوچھتا ہے اور آپ کو کام کرنے کا نتیجہ بتاتا ہے، تو کیا یہ بہتر نہیں ہوگا کہ پہلے اسے نیچے رکھ دیا جائے؟ وہ سوال/نتیجہ نہ صرف آپ کا نقطہ آغاز ہے بلکہ آپ کا حوالہ بھی ہے۔ آپ کی کوڈنگ کے کسی بھی مرحلے پر، آپ اس بات کو یقینی بنانے کے لیے اسے دیکھ سکتے ہیں کہ آپ اس کی طرف کام کر رہے ہیں اور یہ کہ آپ صحیح راستے پر ہیں۔
لہذا چاہے آپ کی جوابی شیٹس میں یا اس خالی A4 پیپر میں جس میں آپ لکھنے والے ہیں، ایک سیکنڈ لے کر شروع کریں اور لکھیں کہ آپ کیا آؤٹ پٹ کرنے کی کوشش کر رہے ہیں۔ اگر آپ نہیں چاہتے ہیں کہ یہ آپ کے جواب کا حصہ بنے تو آپ اسے حاشیے یا کونے میں رکھ سکتے ہیں۔ بس اس بات کو یقینی بنائیں کہ یہ ایسی جگہ ہے جہاں آپ اس کا حوالہ دیتے رہ سکتے ہیں۔
اپنے کوڈ کا خاکہ بنائیں
یہ قدم دو دھاری تلوار کی طرح ہے۔ یہ آپ کو اپنے پروگرام کا روڈ میپ حاصل کر سکتا ہے یا آپ کا وقت ضائع کر سکتا ہے۔ میرا کام یہ یقینی بنانا ہے کہ یہ سابقہ ہے۔
لہذا، سب سے پہلے، میں یہ کہنا چاہتا ہوں: اگر آپ کے مسئلے یا سوال کا دائرہ چھوٹا ہے تو آؤٹ لائننگ کوڈ غیر ضروری ہے۔ ایک بار پھر، یہ عمل تمام منصوبوں یا حالات کے لیے نہ تو نسخہ ہے اور نہ ہی عالمگیر۔ تصور کریں کہ میں آپ کا انٹرویو لینے والا ہوں، اور میں آپ سے یہ لکھنے کو کہتا ہوں کہ CSS کا استعمال کرتے ہوئے ویب پیج میں کسی عنصر کو زیادہ سے زیادہ طریقوں سے کیسے سنٹر کیا جائے۔ آپ کو اس کے لیے قطعی طور پر کسی خاکہ کی ضرورت نہیں ہوگی۔ کوڈ کے ٹکڑے ہر طریقہ کے لیے نسبتاً چھوٹے ہیں۔
لیکن اب، ہم کہتے ہیں کہ میں آپ کو ایک ویب ایپلیکیشن لکھنے کے لیے تفویض کرتا ہوں جو ٹچ اسکرین انٹرفیس کے ذریعے صارف کے دستخط حاصل کرتا ہے اور پھر دستخط کو سرور پر محفوظ کرتا ہے۔ اتنا سیدھا نہیں، ٹھیک ہے؟ آپ کو معلوم کرنے کے لیے ایک سے زیادہ چیزیں ہیں۔ شاید، ایک چھوٹا سا خاکہ مدد کر سکتا ہے.
- دستخط کیپچر کرنے کے لیے UI - HTML کینوس؟ WebGL؟
- جب صارف سائن کر رہا ہو تو باقی ویب پیج پر پوائنٹر ایونٹس کو غیر فعال کریں۔
- کیپچر کی گئی تصویر کو PNG فائل — JS میں تبدیل اور محفوظ کریں۔
- پھر اسے بلاب (شاید) میں تبدیل کریں اور اسے وزیٹر کے لاگ ڈیٹا ٹیبل میں محفوظ کریں۔
میں نے کارروائیوں کی ایک کھردری ترتیب لکھی ہے میرے خیال میں مجھے کوڈ کرنا پڑ سکتا ہے۔ یہ چھوٹا یا لمبا ہو سکتا تھا، اس پر منحصر ہے کہ میں اس سے کیا چاہتا ہوں۔
میں کلائنٹ پراجیکٹس کے لیے خاکہ کوڈ کی انتہائی سفارش کرتا ہوں۔ اپنی صارف کی ضروریات کے ساتھ خاکہ لکھیں یا آپ نے پرنٹ کیے ہوئے تار فریم کے پیچھے لکھیں۔
بلٹ پوائنٹس کا آپ کا فوری اسنیپ شاٹ آپ کو ایک نقشہ، ایک کرنے کی فہرست اور ایک چیک لسٹ فراہم کرتا ہے جس کی توثیق کے لیے جب آپ پروجیکٹ کے اختتام پر پہنچ جاتے ہیں - کافی حد تک آپ کے پورے پروجیکٹ کا خلاصہ کم مخلصی کی فہرست میں۔ یہ آپ کے اگلے اسی طرح کے پروجیکٹ کو شروع کرنے کے لیے ایک ٹیمپلیٹ بھی بن سکتا ہے۔
لیکن جیسا کہ میں نے پہلے کہا، یہ قدم دو دھاری تلوار کی طرح ہے۔ جب وقت کی کمی ہو تو آپ کو امتحان لینے والوں اور انٹرویو لینے والوں کے لیے یہ مختصر رکھنا پڑے گا۔
اگر آپ نہیں جانتے کہ کہاں سے شروع کرنا ہے، تو صرف تین ضروری فنکشنز کو لکھیں جو آپ کو اپنی درخواست میں کوڈ کرنے ہوں گے، اور اگر آپ کے پاس وقت ہے تو اسے پانچ بنائیں۔
لیکن اس کے بارے میں ہے. اس پر جتنا ممکن ہو کم وقت گزاریں، اور تفصیلات پر پسینہ نہ آنے دیں۔ آؤٹ لائن آپ کو اضافی پوائنٹس اسکور نہیں کرے گی۔ یہ صرف اس بات کو یقینی بنانے میں آپ کی مدد کرنے کے لیے ہے کہ آپ کے پاس ہر چیز کا احاطہ ہے۔ یہ آپ کے ابتدائی گٹ ردعمل کو پکڑتا ہے اور آپ کو پروجیکٹ کی زندگی بھر ایماندار رکھتا ہے۔
لانگ ہینڈ بمقابلہ شارٹ ہینڈ
کوڈنگ شروع کرنے کا وقت۔ تو، آپ کیا لکھتے ہیں؟ "Bdrs" یا "border-radius"; "div -> p"یا"<div><p></div></p>"; "pl()"یا"println()"; "q()"یا"querySelector()"؟
اگر کوئی اور آپ کے کوڈ کی درجہ بندی کر رہا ہے، تو پھر کوئی چارہ نہیں ہے۔ مخففات، سیوڈو کوڈز، ایمیٹ شارٹ کٹس، اور شارٹ ہینڈ تحریر کی کوئی دوسری شکل چھوڑ دیں۔ بصورت دیگر، یہ فرض کرنے کی کوئی وجہ نہیں ہے کہ جو بھی اسے پڑھتا ہے وہ جانتا ہے کہ آپ کے مخففات کا کیا مطلب ہے۔
یہ واقعی آپ پر منحصر ہے۔
اگر آپ ہاتھ سے لکھنے کے ساتھ رابطے سے باہر ہو گئے ہیں - اور ہم میں سے بہت سے ہیں - تو بہتر ہے کہ لانگ ہینڈ اشارے کے ساتھ زیادہ نہ جائیں، کیونکہ وہ تکلیف دہ ہو جاتے ہیں۔ ایک ہی وقت میں، ایسی کوئی چیز نہیں ہے کہ آپ کی تحریر کے ساتھ بہت سستی ہو۔ نہیں اگر آپ چاہتے ہیں کہ ایک دن اس پر دوبارہ نظر ڈالیں اور سمجھیں کہ آپ نے کیا لکھا ہے۔
میرے پاس میری نوٹ لینے والی ایپ میں ایک کھلی فائل ہے اور میری میز پر ایک قطار والا نوٹ پیڈ ہے جہاں میں کوڈ کے ٹکڑوں کو لکھتا ہوں جسے میں بعد میں حوالہ کے لیے محفوظ کرنا چاہتا ہوں۔ وہ غیر منظم ہیں، صرف ٹکڑوں کا ایک طویل سلسلہ۔ یہی وجہ ہے کہ جب میں پرانے نوٹوں کو براؤز کرتا ہوں تو مجھے نہیں معلوم ہوتا کہ اگر میں نے انہیں واضح طور پر نہ لکھا ہوتا تو میں لکھنے کا کیا مطلب رکھتا۔
میں ہر وقت نحو کو بھول جاتا ہوں۔ مثال کے طور پر، میں جاوا اسکرپٹ کے فنکشنز کے لیے تیر کا نشان استعمال کر رہا ہوں جب سے یہ متعارف کرایا گیا تھا (کیونکہ یہ چھوٹا ہے)، اور مجھے پورا یقین ہے کہ اگر کوئی اچانک مجھ سے کسی فنکشن کی وضاحت کرنے کے لیے کہے function کلیدی لفظ، میں قوسین یا فنکشن کا نام بھی غلط جگہ پر رکھ سکتا ہوں، جس سے نحوی غلطی کو ہوا دی جائے۔
یہ ہمارے لیے غیر معمولی بات نہیں ہے کہ ہم نحو کو بھول جائیں جنہیں ہم نے کچھ عرصے سے استعمال نہیں کیا ہے۔ یہی وجہ ہے کہ جب آپ جانتے ہوں کہ آپ کو مستقبل کے حوالے کے لیے ان کی ضرورت ہے تو اپنے نوٹ کو واضح طور پر لکھنا بہتر ہے۔
کوڈ کا غیر ترتیب وار بہاؤ
آخری مرحلے کے برعکس، جو آپ میں سے انٹرویو لینے والوں اور ٹیسٹ لینے والوں پر لاگو نہیں ہوتا، یہ خاص طور پر آپ کے لیے تیار کیا جاتا ہے۔
زیادہ تر پروگرامنگ زبانوں کی تشریح، مرتب، اور عمل درآمد کیا جاتا ہے تاکہ بعض اوقات ماخذ میں پہلے سے تحریر شدہ کوڈ کو بعد میں کال کرنے پر عمل میں لایا جاتا ہے۔ ہم اسے جاوا اسکرپٹ میں کرتے ہیں، مثال کے طور پر، فنکشن کالنگ کے ساتھ — فنکشنز کی ابتدائی طور پر تعریف کی جا سکتی ہے، پھر بعد میں عمل میں لایا جا سکتا ہے۔ امتحان لینے والے اور انٹرویو لینے والے پہلے آپ کے جواب کے اہم نکتے پر کام شروع کرنے کے لیے اس کا استعمال کر سکتے ہیں۔
جیسا کہ میں نے شروع سے ہی کہا ہے، ہینڈ رائٹنگ کوڈ کا مقصد آپ کے پروگرام کے ذریعے کام کرنا یا اس کی منطق کو جانچنا ہے۔ یہ سب سے بہتر ہے جب آپ اسے پہلے حل کرنے پر توجہ دیں۔
آئیے ایک کلاسک نصابی کتاب کی مثال لیتے ہیں — nth تلاش کرنے کا پروگرام فبونیکی نمبر. اگر میں اس کے لیے ایک سادہ خاکہ لکھوں تو یہ کچھ اس طرح ہوگا:
- ان پٹ حاصل کریں۔
- فبونیکی نمبر کا حساب لگائیں۔
- آؤٹ پٹ کا خلاصہ کریں۔
- آؤٹ پٹ پرنٹ کریں۔
اس خاکہ میں تمام اقدامات ضروری ہیں۔ تاہم، 1، 3، اور 4 زیادہ واجب ہیں۔ وہ ضروری ہیں لیکن اتنے اہم نہیں کہ فوری توجہ مرکوز کر سکیں۔
ان پٹ کو حاصل کرنے کے بجائے فبونیکی نمبر کا حساب لگانے کے لیے کوڈ لکھنا شروع کرنا بہتر ہے۔ اسے ایک فنکشن میں لپیٹیں، پھر آگے بڑھیں اور کوڈ کو ترتیب وار لکھیں اور جہاں مناسب ہو اس فنکشن کو کال کرنے کے لیے ایک لائن لکھیں۔
اپنا وقت کوڈ لکھنے میں صرف کریں جو مسئلہ کے دل پر مرکوز ہو۔
حقیقی پیشہ ور آگے بڑھ سکتے ہیں۔ چلیں کہتے ہیں کہ میرے پاس ایک کلائنٹ پروجیکٹ ہے، اور مجھے کچھ مثلث جیومیٹری کے ساتھ کام کرنا ہے — دو رخ ملے، مخالف زاویہ، اور تیسرے رخ کی لمبائی تلاش کرنی ہے۔ اور میں نے اپنا کھولنے کے بجائے شروع کرنے کے لیے کاغذ پر لکھنے کا فیصلہ کیا ہے۔ IDE.
پہلے، میں مثلث کھینچوں گا، یقیناً (یہ وہ چیز ہے جس کا میں بہت تجربہ کار ہوں، جیسا کہ آپ بتا سکتے ہیں)۔ میں کچھ نمونے کی لمبائی اور زاویہ لکھوں گا۔ پھر میں فارمولہ لکھوں گا (یقینی طور پر آن لائن تلاش کی تعریفیں) اور پھر میں فنکشن کے لیے کوڈ پر دائیں کود جاؤں گا۔
میرے لیے ضروری اقدامات کو لکھنے کا کوئی فائدہ نہیں ہے حالانکہ مجھے پروڈکشن کے لیے تیار کوڈ میں ان کی ضرورت ہوگی۔ لیکن اگر مجھے امتحان میں جوابی شیٹ پر یہ لکھنا پڑے تو یہ الگ ہوگا۔ میں دوسرے مراحل کو نہیں چھوڑ سکتا۔ تاہم، میں اب بھی فارمولے کے کوڈ سے شروع کر سکتا ہوں۔
چھدم کوڈ
کرس پہلے ہی لکھ چکے ہیں۔ چھدم کوڈ پر آسان مضمون کہ میں آپ کو ایک ٹھوس پڑھنے کی سفارش کرتا ہوں۔
ان تمام پیشہ ور افراد کے لیے جو پوری ہینڈ رائٹنگ کوڈ کی طرح محسوس کرتے ہیں کہ چیز آپ کے چائے کے کپ کی طرح نہیں لگتی ہے لیکن پھر بھی یہ آپ کی مدد کر سکتی ہے، تو چھدم کوڈ ہو سکتا ہے وہ بیلنس ہو جس کی آپ تلاش کر رہے ہیں۔
یہ کوڈ کا خاکہ بنانے کے مترادف ہے، جیسا کہ میں نے پچھلے مراحل میں سے ایک میں ذکر کیا ہے۔ تاہم، یہ مختصر ہے اور شارٹ ہینڈ کوڈنگ کی طرح محسوس ہوتا ہے۔ اسے بعض اوقات "کنکال کوڈ" بھی کہا جاتا ہے۔
سی ایس ایس گرڈ لے آؤٹ کے لیے کچھ فوری چھدم کوڈ یہ ہیں:
Grid
5 60px rows
6 100px columnsلکھنے کو بہت کچھ نہیں ہے! لہٰذا، اگرچہ کاغذ پر پنسل لگانا اس قسم کی چیز کے لیے بہترین ہے، لیکن یہ اتنا ہی موثر، تیز اور سستا ہے کہ آپ جو بھی پروگرام استعمال کر رہے ہیں اس میں کچھ چھدم کوڈ لکھنا۔
جگہ اور تبصرے۔
مجھے یقین ہے کہ کوڈ 90% کلیدی الفاظ اور 10% ٹیبز ہے۔ خالی جگہ کے بغیر الفاظ کی پڑھنے کی اہلیت کم ہو جاتی ہے۔ ہاتھ سے لکھے ہوئے کوڈ کے لیے بھی اشارے ضروری ہیں۔ تاہم، براہ کرم اسے ہر سطح کے لیے استعمال نہ کریں کیونکہ کاغذ کی چوڑائی آپ کو محدود کر دے گی۔ خالی جگہوں کو سمجھداری سے استعمال کریں، لیکن ان کا استعمال کریں.
اگر آپ اپنے استعمال کے لیے کوڈ لکھ رہے ہیں، تو میں یہ بھی مانتا ہوں کہ اگر آپ نے اب تک میں نے جو کچھ بھی بتایا ہے اس پر عمل کیا ہے اور آپ کا آؤٹ پٹ اور صفحہ پر ایک خاکہ پہلے ہی لکھ دیا ہے، تو آپ کو تبصرے شامل کرنے کی بھی ضرورت نہیں ہوگی۔ تبصرے آپ کو جلدی بتاتے ہیں کہ اس کے درج ذیل کوڈ کا سیٹ کیا کرتا ہے۔ اگر آپ پہلے ہی کوڈ کے لیے خاکہ لکھ چکے اور پڑھ چکے ہیں، تو تبصرے بے کار نوٹ ہیں۔
تاہم، اگر آپ کا فیصلہ ایک کو نیچے رکھنے کے لیے کہتا ہے، تو ایسا کریں۔ اسے کوڈ کے دائیں جانب شامل کریں (چونکہ آپ اسے پہلے سے لکھی ہوئی لائنوں کے درمیان اس طرح داخل نہیں کر پائیں گے جس طرح آپ کہہ سکتے ہیں، VS کوڈ)۔ فارورڈ سلیشس، بریکٹ یا تیر کا استعمال اس بات کی نشاندہی کرنے کے لیے کریں کہ وہ تبصرے ہیں۔
امتحان دینے والوں کے لیے جو کسی مخصوص نحو سے غیر مطمئن ہیں، تبصرے لکھیں۔ اس طرح، کم از کم، آپ اپنے کاغذ کی درجہ بندی کرنے والے شخص کو اس غلط فارمیٹ شدہ کوڈ کے ساتھ اپنے ارادے سے آگاہ کر رہے ہیں۔ اور تبصروں کو ظاہر کرنے کے لیے صرف درست حد بندیوں کا استعمال کریں — مثال کے طور پر، یہ جاوا اسکرپٹ کے لیے فارورڈ سلیشز ہوں گے۔
ینالاگ بمقابلہ ڈیجیٹل۔
جیسا کہ میں نے پہلے ذکر کیا ہے، جو کچھ میں یہاں فراہم کر رہا ہوں وہ عام کوڈنگ مشورہ ہے۔ اگر آپ اسے فزیکل پیپر کے ساتھ آزمانا نہیں چاہتے ہیں تو کوئی بھی نوٹ لینے والی ایپلیکیشن بھی کام کرتی ہے۔
لیکن اگر آپ ڈیجیٹل روٹ کو آزمانے جا رہے ہیں تو، میری سفارش یہ ہے کہ براہ راست نوٹ لینے والی ایپ کے علاوہ کچھ اور استعمال کرنے کی کوشش کریں۔ مزید بصری ڈیجیٹل ٹولز کے ساتھ کام کریں — فلو ڈایاگرام، ذہن کے نقشے، وائر فریم وغیرہ۔ وہ آپ کے نتائج، خاکہ اور خود کوڈ کو دیکھنے میں آپ کی مدد کر سکتے ہیں۔
میں زیادہ ڈیجیٹل شہری نہیں ہوں (سوائے ویب پر کام کرنے اور حال ہی میں ای بک پڑھنے میں تبدیل ہونے کے)، اس لیے میں فزیکل نوٹ بکس پر قائم رہتا ہوں۔
ہینڈ رائٹنگ کوڈ کے لیے میرے پسندیدہ ٹولز
کوئی پنسل اور کاغذ کرے گا! لیکن وہاں بہت سارے اختیارات موجود ہیں، اور یہ چند انتخابی ٹولز ہیں جو میں استعمال کرتا ہوں:
کوڈ کرنے کا کوئی "لکھنے" کا طریقہ نہیں ہے۔
مجھے امید ہے کہ اگر اور کچھ نہیں تو پنسل اور کاغذ کے ساتھ ہینڈ رائٹنگ کوڈ کا میرا چھوٹا سا طریقہ آپ کو اس طریقہ کا اندازہ لگاتا ہے جس طرح آپ پہلے سے منصوبہ بندی کرتے ہیں اور کوڈ لکھتے ہیں۔ مجھے یہ جاننا پسند ہے کہ دوسرے ڈویلپر اپنے کام تک کیسے پہنچتے ہیں، اور یہ میرا طریقہ ہے کہ میں آپ کو جس طرح سے کام کرتا ہوں اس میں جھانکتا ہوں۔
ایک بار پھر، یہاں کچھ بھی سائنسی یا قطعی آرٹ نہیں ہے۔ لیکن اگر آپ ہاتھ سے لکھے ہوئے کوڈ کو آزمانے کی منصوبہ بندی کرنا چاہتے ہیں، تو یہاں وہ سب کچھ ہے جسے ہم نے ایک اچھی ترتیب شدہ فہرست میں شامل کیا ہے:
- اپنے کوڈ کی آؤٹ پٹ (اگر ضرورت ہو تو نمونے کے ڈیٹا کے ساتھ) لکھ کر شروع کریں۔
- کوڈ کے لیے ایک خاکہ لکھیں۔ براہ کرم چھوٹے منصوبوں یا کم پیچیدہ منصوبوں کے لیے اسے تین مراحل پر رکھیں۔
- لانگ ہینڈ اشارے استعمال کریں۔ اپنے لیے لکھنے والے شارٹ ہینڈ اشارے استعمال کر سکتے ہیں جب تک کہ تحریر قابلِ فہم ہو اور جب آپ بعد میں اس کا حوالہ دیتے ہیں تو آپ کو سمجھ آتی ہے۔
- جب کسی وقت کی پابندی کے تحت، اس کوڈ کو لکھنے پر غور کریں جو پہلے مسئلے کے دل سے نمٹے۔ بعد میں، اپنے ترتیب وار کوڈ میں صحیح جگہ پر اس کوڈ پر کال لکھیں۔
- اگر آپ پراعتماد محسوس کرتے ہیں تو، مرکزی خیال کو مخاطب کرتے ہوئے سیوڈو کوڈ لکھنے کی کوشش کریں۔
- مناسب اشارے اور خالی جگہوں کا استعمال کریں - اور کاغذ کی چوڑائی کا خیال رکھیں۔
یہی ہے! جب آپ ہاتھ سے کوڈ لکھنے کی کوشش کرنے کے لیے تیار ہوں، مجھے امید ہے کہ یہ مضمون آپ کے لیے شروع کرنا آسان بنا دے گا۔ اور اگر آپ امتحان یا انٹرویو کے لیے بیٹھے ہیں، تو مجھے امید ہے کہ اس سے آپ کو سوالات کو درست کرنے پر توجہ دینے میں مدد ملے گی۔
