اہم نکات
1. صاف اور قابل پڑھائی کوڈ لکھیں
کوڈ کے معیار کی واحد درست پیمائش: WTFs/minute
پڑھنے کی قابلیت سب سے اہم ہے۔ صاف کوڈ کو دوسرے ڈویلپرز کے لیے آسانی سے سمجھا جا سکنا چاہیے۔ یہ سادہ، خوبصورت، اور بے ترتیبی سے پاک ہونا چاہیے۔ کوشش کریں کہ ایسا کوڈ لکھیں جو اپنی نیت کو واضح طور پر بیان کرے بغیر اس کے کہ تفصیلی تبصروں کی ضرورت ہو۔ معنی خیز متغیرات اور فنکشن کے نام استعمال کریں، فنکشنز کو چھوٹا اور مرکوز رکھیں، اور کوڈ کو منطقی طور پر منظم کریں۔
قابل دیکھ بھال ہونے کی صلاحیت ترقی کو ممکن بناتی ہے۔ ایسا کوڈ جو تبدیل کرنے میں مشکل ہو، ایک بوجھ بن جاتا ہے۔ اپنے کوڈ کو لچکدار اور ماڈیولر بنائیں تاکہ یہ بدلتی ہوئی ضروریات کے مطابق ڈھل سکے۔ DRY (اپنے آپ کو نہ دہرائیں) اور SOLID جیسے اصولوں کی پیروی کریں تاکہ کمزور جڑے ہوئے، انتہائی ہم آہنگ نظام بن سکیں۔ کوڈ کی ساخت کو بہتر بنانے کے لیے بے رحمی سے ریفیکٹر کریں بغیر اس کے کہ رویے میں تبدیلی آئے۔
صاف کوڈ کا فائدہ ہوتا ہے۔ اگرچہ صاف کوڈ لکھنے میں ابتدائی طور پر زیادہ محنت درکار ہوتی ہے، لیکن یہ طویل مدت میں کافی وقت اور ذہنی دباؤ بچاتا ہے۔ صاف کوڈ کو ڈیبگ کرنا، بڑھانا، اور دیکھ بھال کرنا آسان ہوتا ہے۔ یہ ڈویلپرز کو زیادہ مؤثر طریقے سے کام کرنے کے قابل بناتا ہے اور تبدیلیوں کے دوران بگ متعارف کرنے کے خطرے کو کم کرتا ہے۔ صاف کوڈ کو اپنی ترقی کی مشق کا ایک بنیادی حصہ بنائیں۔
2. معنی خیز نام رکھنے کے طریقے اپنائیں
ایک متغیر، فنکشن، یا کلاس کا نام تمام بڑے سوالات کا جواب دینا چاہیے۔ یہ بتانا چاہیے کہ یہ کیوں موجود ہے، یہ کیا کرتا ہے، اور اسے کیسے استعمال کیا جاتا ہے۔
نیت کو ظاہر کرنے والے نام استعمال کریں۔ ایسے نام منتخب کریں جو متغیرات، فنکشنز، اور کلاسز کے مقصد اور رویے کو واضح طور پر بیان کریں۔ ایک حرفی ناموں یا خفیہ اختصارات سے پرہیز کریں۔ ایسے نام استعمال کریں جو بولنے میں آسان ہوں اور جنہیں آسانی سے تلاش کیا جا سکے۔ مثال کے طور پر:
- برا: d (دنوں میں گزرے وقت)
- اچھا: elapsedTimeInDays
ہمیشہ اور درست رہیں۔ اپنے کوڈ بیس میں مستقل نام رکھنے کے طریقے استعمال کریں۔ ابہام سے بچنے کے لیے درست رہیں - مثلاً، معنی خیز تفریق جیسے getActiveAccounts() اور getActiveAccountInfo() کا استعمال کریں۔ ایسے انکوڈنگ یا پیشگی ناموں سے پرہیز کریں جو بغیر کسی قیمت کے شور پیدا کرتے ہیں۔ کلاس کے نام اسم ہونے چاہئیں، جبکہ طریقوں کے نام فعل ہونے چاہئیں۔
نام کی لمبائی دائرہ کار کے مطابق ہونی چاہیے۔ بڑے دائرہ کار کے لیے متغیرات اور فنکشنز کے لیے طویل، زیادہ وضاحتی نام استعمال کریں۔ چھوٹے نام چھوٹے، مقامی دائرہ کار کے لیے قابل قبول ہیں۔ نام کی لمبائی اس کے استعمال کے دائرہ کار کے تناسب میں ہونی چاہیے۔ جہاں نام استعمال ہوتا ہے، وہاں پڑھنے کی قابلیت اور سمجھ بوجھ کے لیے بہتر بنائیں۔
3. فنکشنز کو چھوٹا اور مرکوز رکھیں
فنکشنز کو ایک ہی کام کرنا چاہیے۔ انہیں یہ اچھی طرح کرنا چاہیے۔ انہیں صرف یہی کرنا چاہیے۔
چھوٹا خوبصورت ہے۔ فنکشنز کو چھوٹا ہونا چاہیے - عام طور پر 5-10 لائنیں۔ انہیں ایک اسکرین پر فٹ ہونا چاہیے اور فوراً سمجھ میں آنا چاہیے۔ طویل، پیچیدہ فنکشنز لکھنے کے بجائے کوڈ کو اچھی طرح نامزد مددگار فنکشنز میں نکالیں۔ چھوٹے فنکشنز کو سمجھنا، جانچنا، اور دیکھ بھال کرنا آسان ہوتا ہے۔
ایک کام کو اچھی طرح کریں۔ ہر فنکشن کا ایک واضح مقصد ہونا چاہیے۔ اگر کوئی فنکشن متعدد کام کر رہا ہے، تو انہیں علیحدہ فنکشنز میں نکالیں۔ یہ علامات کہ کوئی فنکشن بہت زیادہ کام کر رہا ہے شامل ہیں:
- متعدد سطحوں کی تج抽
- متعدد سیکشنز یا کوڈ بلاکس
- متعدد پیرامیٹرز
ایک سطح کی تج抽 برقرار رکھیں۔ ایک فنکشن کے اندر بیانات سب ایک ہی سطح کی تج抽 پر ہونے چاہئیں۔ اعلی سطحی منطق کو کم سطحی تفصیلات کے ساتھ نہ ملائیں۔ کم سطحی کارروائیوں کو علیحدہ فنکشنز میں نکالیں۔ یہ پڑھنے کی قابلیت کو بہتر بناتا ہے کیونکہ فنکشنز کو مرکوز اور تصوراتی طور پر سادہ رکھتا ہے۔
4. مناسب فارمیٹنگ اور تنظیم کی مشق کریں
کوڈ کی فارمیٹنگ مواصلات کے بارے میں ہے، اور مواصلات پیشہ ور ڈویلپر کا پہلا کام ہے۔
مستقل فارمیٹنگ اہم ہے۔ اپنے کوڈ میں مستقل انڈینٹیشن، لائن بریک، اور اسپیسنگ کا استعمال کریں۔ یہ پڑھنے کی قابلیت کو بہتر بناتا ہے اور ذہنی بوجھ کو کم کرتا ہے۔ اپنی ٹیم کے ساتھ فارمیٹنگ کے معیارات پر اتفاق کریں اور انہیں نافذ کرنے کے لیے خودکار ٹولز کا استعمال کریں۔ اہم فارمیٹنگ کی رہنما خطوط میں شامل ہیں:
- مناسب انڈینٹیشن
- مستقل بریکٹ کی جگہ
- منطقی لائن بریک
- مناسب سفید جگہ
کوڈ کو منطقی طور پر منظم کریں۔ متعلقہ کوڈ کو ایک ساتھ گروپ کریں اور غیر متعلقہ کوڈ کو الگ کریں۔ منطقی سیکشنز کے درمیان "پیراگراف" وقفے پیدا کرنے کے لیے خالی لائنوں کا استعمال کریں۔ متعلقہ فنکشنز کو قریب رکھیں۔ فائلوں کو ایک ہی تصور یا جزو پر مرکوز رکھیں۔ جب مناسب ہو تو بڑی فائلوں کو چھوٹی، زیادہ مرکوز فائلوں میں تقسیم کریں۔
معیاری طریقوں کی پیروی کریں۔ اپنی زبان اور کمیونٹی کے لیے معیاری طریقوں کی پیروی کریں۔ یہ آپ کے کوڈ کو دوسرے ڈویلپرز کے لیے زیادہ واقف اور قابل رسائی بناتا ہے۔ مثال کے طور پر، جاوا میں:
- کلاس کے نام PascalCase استعمال کرتے ہیں
- طریقوں کے نام camelCase استعمال کرتے ہیں
- مستقل متغیرات ALL_CAPS استعمال کرتے ہیں
5. انحصار کا انتظام کریں اور تکرار سے بچیں
تکرار سافٹ ویئر میں تمام برائیوں کی جڑ ہو سکتی ہے۔
تکرار کو ختم کریں۔ دہرایا گیا کوڈ ایک تج抽 کا موقع ہے۔ جب آپ تکرار دیکھیں، تو مشترکہ کوڈ کو دوبارہ استعمال کے قابل فنکشن یا کلاس میں نکالیں۔ یہ منطق کو مرکزی بنانے اور غیر متوازن تبدیلیوں کے خطرے کو کم کرنے کے ذریعے دیکھ بھال کی صلاحیت کو بہتر بناتا ہے۔ تکرار کی اقسام پر نظر رکھیں:
- ایک جیسے کوڈ بلاکس
- معمولی تغیرات کے ساتھ مشابہ الگورڈمز
- دہرائی گئی switch/case یا if/else زنجیریں
انحصار کا احتیاط سے انتظام کریں۔ ماڈیولز کے درمیان انحصار کو کم سے کم کریں تاکہ جڑت کو کم کیا جا سکے۔ کوڈ کو زیادہ ماڈیولر اور جانچنے کے قابل بنانے کے لیے انحصار کی انجیکشن اور کنٹرول کی تبدیلی کا استعمال کریں۔ انحصار کی تبدیلی کے اصول کی پیروی کریں - تج抽ات پر انحصار کریں، ٹھوس چیزوں پر نہیں۔ یہ آپ کے کوڈ کو زیادہ لچکدار اور تبدیل کرنے میں آسان بناتا ہے۔
کم سے کم علم کے اصول کا استعمال کریں۔ ایک ماڈیول کو ان اشیاء کے اندرونی معاملات کے بارے میں نہیں جاننا چاہیے جن کے ساتھ وہ کام کرتا ہے۔ یہ ماڈیولز کے درمیان جڑت کو کم کرتا ہے۔ مثال کے طور پر، ڈیمٹر کے قانون کا استعمال کریں - ایک طریقہ صرف ان طریقوں کو کال کرنا چاہیے:
- اپنی ہی چیز
- اشیاء جو پیرامیٹرز کے طور پر منتقل کی گئی ہیں
- اشیاء جو وہ تخلیق کرتا ہے
- اس کے براہ راست جزو کی اشیاء
6. غلطیوں کو خوش اسلوبی سے سنبھالیں
غلطی کا ہینڈلنگ اہم ہے، لیکن اگر یہ منطق کو چھپاتا ہے تو یہ غلط ہے۔
غلطی کے کوڈز کے بجائے استثنائیات کا استعمال کریں۔ استثنائیات زیادہ صاف ہیں اور آپ کے کوڈ کی بنیادی منطق کو بے ترتیبی سے پاک رکھتی ہیں۔ یہ خوشگوار راستے سے غلطی کے ہینڈلنگ کو الگ کرنے کی اجازت دیتی ہیں۔ استثنائیات کا استعمال کرتے وقت:
- معلوماتی غلطی کے پیغامات بنائیں
- استثنائیات کے ساتھ سیاق و سباق فراہم کریں
- کالر کی ضروریات کی بنیاد پر استثنائی کلاسز کی تعریف کریں
نل واپس نہ کریں۔ نل واپس کرنے سے نل پوائنٹر کی غلطیاں پیدا ہوتی ہیں اور کوڈ کو نل چیک کے ساتھ بے ترتیبی سے بھر دیتی ہیں۔ اس کے بجائے:
- فہرستوں کے لیے نل کے بجائے خالی مجموعے واپس کریں
- نل آبجیکٹ پیٹرن کا استعمال کریں
- جاوا میں Optional یا فنکشنل زبانوں میں Maybe کا استعمال کریں
try-catch-finally کے بیانات پہلے لکھیں۔ جب آپ ایسا کوڈ لکھ رہے ہوں جو استثنائیات پھینک سکتا ہے تو try-catch-finally سے شروع کریں۔ یہ کالنگ کوڈ کے لیے دائرہ اور توقعات کو متعین کرنے میں مدد کرتا ہے۔ یہ یقینی بناتا ہے کہ وسائل کو صحیح طریقے سے منظم اور جاری کیا جائے، یہاں تک کہ غلطی کے منظرناموں میں بھی۔
7. مکمل یونٹ ٹیسٹ لکھیں
ٹیسٹ کوڈ پیداوار کے کوڈ کی طرح ہی اہم ہے۔
TDD کے تین قوانین کی پیروی کریں۔ ٹیسٹ ڈرائیوڈ ڈویلپمنٹ (TDD) کوڈ کے معیار اور ڈیزائن کو بہتر بناتا ہے:
- پیداوار کے کوڈ لکھنے سے پہلے ایک ناکام ٹیسٹ لکھیں
- ناکامی کو ظاہر کرنے کے لیے صرف اتنا ہی ٹیسٹ لکھیں
- ٹیسٹ پاس کرنے کے لیے صرف اتنا ہی پیداوار کا کوڈ لکھیں
ٹیسٹ کو صاف اور قابل دیکھ بھال رکھیں۔ اپنے ٹیسٹ کے لیے بھی کوڈ کے معیار کے وہی معیارات لاگو کریں جو آپ کے پیداوار کے کوڈ کے لیے ہیں۔ باقاعدگی سے ٹیسٹ کو ریفیکٹر اور بہتر بنائیں۔ اچھی طرح سے منظم ٹیسٹ دستاویزات کے طور پر کام کرتے ہیں اور پیداوار کے کوڈ کی بے خوف ریفیکٹرنگ کو ممکن بناتے ہیں۔
جامع ٹیسٹ کوریج کا ہدف بنائیں۔ ایسے ٹیسٹ لکھیں جو کنارے کے معاملات، سرحدی حالات، اور غلطی کے منظرناموں کا احاطہ کریں - صرف خوشگوار راستے کو نہیں۔ ٹیسٹ کوریج میں خلا کی نشاندہی کرنے کے لیے کوڈ کوریج کے ٹولز کا استعمال کریں۔ یاد رکھیں کہ 100% کوریج بگ فری کوڈ کی ضمانت نہیں دیتی، لیکن یہ ریفیکٹرنگ اور تبدیلیوں میں اعتماد فراہم کرتی ہے۔
8. کوڈ کو مسلسل ریفیکٹر کریں
کیمپ گراونڈ کو اس سے زیادہ صاف چھوڑیں جتنا آپ نے پایا۔
موقع پر ریفیکٹر کریں۔ جب بھی آپ کسی کوڈ کے ٹکڑے پر کام کریں تو کوڈ کی ساخت کو بہتر بنائیں۔ بوائے اسکاوٹ کے اصول کی پیروی کریں: کوڈ کو بہتر چھوڑیں جتنا آپ نے پایا۔ چھوٹے، تدریجی بہتریاں وقت کے ساتھ جمع ہوتی ہیں اور کوڈ کی بربادی کو روکتی ہیں۔ عام ریفیکٹرنگ کی تکنیکوں میں شامل ہیں:
- طریقوں یا کلاسز کو نکالنا
- وضاحت کے لیے نام تبدیل کرنا
- پیچیدہ شرطوں کو سادہ بنانا
- تکرار کو ختم کرنا
ٹیسٹ کے ساتھ محفوظ طریقے سے ریفیکٹر کریں۔ ریفیکٹرنگ سے پہلے ہمیشہ ایک مضبوط ٹیسٹ کا مجموعہ رکھیں۔ چھوٹے، تدریجی تبدیلیاں کریں اور باقاعدگی سے ٹیسٹ چلائیں۔ یہ آپ کو یقین دلاتا ہے کہ آپ کی تبدیلیاں موجودہ فعالیت کو توڑ نہیں رہی ہیں۔ جب دستیاب ہوں تو خودکار ریفیکٹرنگ کے ٹولز کا استعمال کریں تاکہ غلطیوں کے متعارف ہونے کے خطرے کو کم کیا جا سکے۔
ریفیکٹرنگ اور قیمت کی ترسیل کے درمیان توازن رکھیں۔ اگرچہ مسلسل ریفیکٹرنگ اہم ہے، لیکن اس سے ترقی میں رکاوٹ نہ آنے دیں۔ "اچھا کافی" کے بجائے کمال کی طرف توجہ دیں۔ ریفیکٹرنگ کی کوششوں کو کوڈ کے سب سے زیادہ مسئلہ دار یا بار بار تبدیل ہونے والے علاقوں پر مرکوز کریں۔ اسٹیک ہولڈرز کو ریفیکٹرنگ کی قیمت کی وضاحت کریں تاکہ جاری کوڈ کی بہتری کے لیے حمایت حاصل ہو۔
9. آبجیکٹ اور فنکشنل پروگرامنگ کے اصولوں کا اطلاق کریں
آبجیکٹس اپنے ڈیٹا کو تج抽ات کے پیچھے چھپاتے ہیں اور اس ڈیٹا پر کام کرنے والے فنکشنز کو ظاہر کرتے ہیں۔ ڈیٹا کے ڈھانچے اپنے ڈیٹا کو ظاہر کرتے ہیں اور ان کے پاس کوئی معنی خیز فنکشن نہیں ہوتا۔
آبجیکٹ اورینٹڈ اصولوں کا عقلمندی سے استعمال کریں۔ لچکدار، ماڈیولر ڈیزائن بنانے کے لیے انکیپسولیشن، وراثت، اور پولی مورفزم جیسے اصولوں کا اطلاق کریں۔ SOLID کے اصولوں کی پیروی کریں:
- واحد ذمہ داری کا اصول
- کھلا-بند اصول
- لِسکوف کی تبدیلی کا اصول
- انٹرفیس کی علیحدگی کا اصول
- انحصار کی تبدیلی کا اصول
فنکشنل پروگرامنگ کے تصورات کا فائدہ اٹھائیں۔ یہاں تک کہ آبجیکٹ اورینٹڈ زبانوں میں بھی، فنکشنل پروگرامنگ کی تکنیکیں صاف کوڈ کی طرف لے جا سکتی ہیں:
- بغیر سائیڈ اثرات کے خالص فنکشنز
- ناقابل تبدیلی ڈیٹا
- اعلی درجے کے فنکشنز
- فنکشن کی ترکیب
مسئلے کے لیے صحیح نقطہ نظر کا انتخاب کریں۔ آبجیکٹ اورینٹڈ اور فنکشنل پیراڈائمز میں ہر ایک کی طاقتیں اور کمزوریاں ہیں۔ جب آپ کو پیچیدہ ڈومینز کی ماڈلنگ کی ضرورت ہو تو آبجیکٹ اورینٹڈ ڈیزائن کا استعمال کریں۔ ڈیٹا کی تبدیلی اور پروسیسنگ کی پائپ لائنز کے لیے فنکشنل طریقوں کا استعمال کریں۔ بہت سی جدید زبانیں ہائبرڈ نقطہ نظر کی حمایت کرتی ہیں، جس سے آپ کو اپنے نظام کے ہر حصے کے لیے بہترین ٹول استعمال کرنے کی اجازت ملتی ہے۔
10. ہم آہنگی پر غور کریں
ہم آہنگی ایک جڑت کی حکمت عملی ہے۔ یہ ہمیں یہ الگ کرنے میں مدد کرتی ہے کہ کیا کیا جاتا ہے اور کب کیا جاتا ہے۔
ہم آہنگی کے چیلنجز کو سمجھیں۔ ہم آہنگ پروگرامنگ پیچیدگی اور لطیف بگ کے امکانات کو متعارف کرتی ہے۔ عام مسائل میں شامل ہیں:
- ریس کی حالتیں
- ڈیڈ لاکس
- گمشدہ سگنل
- میموری کی مرئی مسائل
ہم آہنگی کے خدشات کو الگ کریں۔ اپنے ہم آہنگی سے متعلق کوڈ کو دوسرے کوڈ سے الگ رکھیں۔ یہ اس پر غور کرنے اور جانچنے میں آسان بناتا ہے۔ ہم آہنگی کا انتظام کرنے کے لیے Executors، Futures، اور Actors جیسے تج抽ات کا استعمال کریں، بجائے اس کے کہ خام دھاگوں کے ساتھ کام کریں۔
ناقابل تبدیلی اور خالص فنکشنز کو ترجیح دیں۔ ناقابل تبدیلی اشیاء اور خالص فنکشنز بنیادی طور پر دھاگہ محفوظ ہوتے ہیں۔ وہ مشترکہ متغیر حالت سے بچ کر بہت سے ہم آہنگی کے مسائل کو ختم کرتے ہیں۔ جب متغیر حالت ضروری ہو تو مناسب ہم آہنگی کی تکنیکوں کا استعمال کریں اور ایٹمی متغیرات یا ہم آہنگ مجموعوں کا استعمال کرنے پر غور کریں۔
آخری تازہ کاری:
FAQ
What's "Clean Code: A Handbook of Agile Software Craftsmanship" about?
- Focus on Clean Code: "Clean Code" by Robert C. Martin emphasizes writing code that is easy to read, understand, and maintain.
- Professionalism in Coding: It argues that clean code is a hallmark of professionalism in software development.
- Practical Advice: The book provides guidelines, examples, and case studies to help developers write clean and efficient code.
Why should I read "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Improve Coding Skills: It teaches how to write code that is clean, efficient, and maintainable.
- Learn from Experts: Part of the Robert C. Martin series, known for its technical and pragmatic approach.
- Long-term Benefits: Writing clean code reduces maintenance costs and makes you a more valuable developer.
What are the key takeaways of "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Code Readability: Emphasizes that code should be easy to read and understand.
- Single Responsibility Principle: Advocates for each class or function to have one reason to change.
- Continuous Improvement: Encourages developers to continuously improve their code, following the Boy Scout Rule.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" define clean code?
- Elegance and Efficiency: Clean code is described as elegant and efficient, with minimal dependencies.
- Readable and Maintainable: It should read like well-written prose, making the designer's intent clear.
- Focused and Single-minded: Each function, class, and module should have a single, clear purpose.
What is the Single Responsibility Principle in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- One Reason to Change: A class or module should have one, and only one, reason to change.
- Improves Cohesion: Ensures that classes are cohesive, with closely related methods and variables.
- Facilitates Maintenance: Makes the code easier to maintain and extend, reducing the impact of changes.
What is the "Boy Scout Rule" mentioned in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Suggests leaving the codebase cleaner than you found it.
- Small, Incremental Changes: Encourages making small improvements, like renaming variables or breaking up functions.
- Professional Responsibility: Presented as a professional responsibility to ensure maintainability.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" approach Test-Driven Development (TDD)?
- Fundamental Discipline: TDD is crucial for writing clean, reliable code.
- Three Laws of TDD: Write a failing test first, write code to pass the test, then refactor.
- Benefits: Helps catch bugs early and improves code design.
What are "code smells" according to "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Definition: Indicators of potential problems that hinder readability or maintainability.
- Examples: Long methods, large classes, and duplicated code.
- Addressing Smells: Provides heuristics and refactoring techniques to improve code quality.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" suggest handling exceptions?
- Prefer Exceptions: Use exceptions instead of error codes for better context and management.
- Provide Context: Include meaningful messages and context when throwing exceptions.
- Avoid Checked Exceptions: Suggests using unchecked exceptions for cleaner code.
What role do unit tests play in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Ensure Code Quality: Unit tests ensure code works as intended and remains maintainable.
- Test-Driven Development: Advocates writing tests before production code.
- Clean and Readable Tests: Tests should be as clean and readable as production code.
What is the role of refactoring in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Refactoring improves code structure and readability without changing functionality.
- Techniques: Provides techniques like Extract Method and Rename Variable to enhance code quality.
- Fearless Refactoring: With comprehensive tests, developers can refactor confidently.
What are the best quotes from "Clean Code: A Handbook of Agile Software Craftsmanship" and what do they mean?
- "Clean code does one thing well." Emphasizes focus and clarity in code.
- "Leave the campground cleaner than you found it." Encourages continuous improvement of the codebase.
- "You know you are working on clean code when each routine you read turns out to be pretty much what you expected." Highlights the importance of readability and predictability.
جائزے
صاف کوڈ اپنی پڑھنے کے قابل، برقرار رکھنے کے قابل کوڈ لکھنے کے اصولوں کے لیے زیادہ تر مثبت جائزے حاصل کرتا ہے۔ قارئین نام رکھنے، فنکشنز، اور ٹیسٹنگ پر عملی مشوروں کی تعریف کرتے ہیں۔ کتاب کا جاوا پر زور اور کچھ زیادہ سخت ہدایات عام تنقید کا نشانہ ہیں۔ بہت سے لوگوں کا خیال ہے کہ یہ ڈویلپرز کے لیے لازمی مطالعہ ہے، حالانکہ کچھ تجربہ کار پروگرامرز کے لیے یہ کم مفید سمجھتے ہیں۔ کیس اسٹڈیز اور ریفیکٹرنگ کی مثالوں کی کچھ لوگوں نے تعریف کی ہے لیکن دوسروں نے انہیں زیادہ سمجھا ہے۔ مجموعی طور پر، جائزہ لینے والے اس بات پر متفق ہیں کہ یہ کتاب کوڈ کے معیار پر قیمتی بصیرت فراہم کرتی ہے، چاہے تمام تجاویز ہر جگہ لاگو نہ ہوں۔
Similar Books
