خلاصه ای از مطالب کتاب Clean Code اثر رابرت مارتین

پرسیده شده
فعالیت 1060 روز پیش
دیده شده 432 بار
1

فصل 3 توابع

-------------------

 

1- توابع باید کوچک و کوچک تر باشند تا خوانایی اون ها به خاطر کوچک بودنشون بهتر بشه

 

2-  یک تابع نباید به اندازه ای بزرگ باشد که بتواند ساختار های تو در تو را نگهداری کند و ساختار های تو در تو در یک تابع نباید بزرگ تر از 1 یا 2 باشد ( ساختار های تو در تو منظور if while و .. ’)

 

3 - تابع باید یک کار انجام دهد و آن را به خوبی انجام دهد و فقط هم همین کار را انجام دهد یکی از راه های شناختن این که تابع بیش از یک کار را انجام  می دهد این است که شما نتونید تابعی با نام دیگری از درون آن استخراج کنید  که صرفا یک بازگویی مجدد از اجرای کار در آن باشد 

 

4- برای نامگزاری نام توابع از عبارت های توصیفی استفاده کنید یک نام توصیفی طولانی بهتر از یک نام کوتاه  مبهم می باشد  همچنین یک نام توصیفی طولانی بهتر از یک کامنت توصیفی طولانی می باشد 

 

5- از یک قرار داد نامگزاری استفاده کنید که اجازه می دهد نام های چندگانه  به راحتی در نام توابع استفاده شود و سپس از کلمات چندگانه استفاده کنید تا بتوانید کاری را که تابع انجام میدهد نشان دهید همچنین از عبارات مشابه اسم ها و فعل هایی که در تابع خود استفاده کرده اید برای نامگذاری ماژول ها استفاده کنید

 

6- بهترین حالت یک تابع برای داشتن آرگومانت این هستش که یا نداشته باشه یا یکی داشته باشه یا هم دو تا و داشتن یک تابع با داشتن آرگومنت های مختلف از نظر تست کار رو برای ما سخت تر میکند سختی نوشتن تمام مورد های آزمون برای اطمینان از اینکه  تمام ترکیبات  مختلف آرگومان وجود داشته باشد کار خیلی سختی هستش

 

7- تابع و آرگومان باید ترکیب از اسم و فعل باشند که باهم هماهنگی داشته باشند

 

8- قانون جدا سازی فرمان و جست و جو توابع ما باید یا به چیزی پاسخ دهند یا اینکه کاری انجام دهند و نه هر دو برای مثال تابع ما باید وضعیت اشیا را تغیر دهد یا اینکه باید برخی  از اطلاعات  مربوط به اشیا را بر گرداند و انجام این دو کار با هم باعث سردرگمی بیشتر می شود

 

9- بلاک های  try / catch در نوع خودشان زشت هستند و ساختار کدمون رو با پیچیدگی مواجه می کنند  و پردازش خطا را با پردازش عادی ترکیب میکنند بنابراین بهتر هستش try / catch  را استخراج و از بدنه کد خود خارج کنید همچنین همان طور که قبلا گفته شد توابع بهتر هستش فقط یک کار رو انجام دهند مدیریت خطا یک کار است بنابراین تابعی که خطاها رو اداره میکند هیچ کار دیگری رو نباید اجرا کند  و اگر اومدیم و از کلمه کلیدی try / catch  استفاده کردیم  باید اولین کلمه تابع باشد و بعد از بلوک  catch / finally  چیز دیگری نباشد 

 

10- سعی شود در انجام یک تابع از انجام یک تکرار جلوگیری شود

 

11- قانون گام به گام ما وقتی میایم و کدمون رو می نویسیم باید شبیه به یک داستان باشد و هر تابع باید  باید توسط توابع که در سطح بعدی انتزاع هستند دنبال شود تا بتوانیم برنامه را بخانیم 

 

12 - عبارات switch تنها با دو مورد بزرگ تر از یک بلوک با عملکرد واحد می باشد و این کار هم سخته که عبارت switch بنویسیم که فقط یک کار رو انجام میدهد چون switch ذاتا n کار رو می تونه انجام بدهدو ما باید موقعی از عبارات switch استفاده کنیم  که در یک کلاس سطح پایین قرار میگیرد و هرگز تکرار نمی شود که این کار رو باید با استفاده از چندریختی یا Polymorphism انجام دهیم و در کل قاعده کلی استفاده از اون ها باید به این شیوه باشند که این ها فقط یک بار ظاهر می شوند  و برای ایجاد اشیا چندریختی استفاده می شود و در پشت رابطه ارث بری پنهان می شودتا بقیه سیستم ها اون هارو نبینند

فایل پیوست

emad ta
emad ta

11 اردیبهشت 00

0
حذف شده

فصل 4 کامنت ها 

------------------------------

 

1 - هر زمانی که  کد خودتان را به درستی نشان دادی باید خودتان را تشویق کنید و هر بار که شما کامنتی می نویسید باید در توانایی خود احساس شکست کنید 

 

2 - اغلب کامنت ها از کدی که در حال توضیفش هستند جدا هستند و دچار افسردگی می شوند به خاطر این که ما اون کد رو غالبا تغیر میدهیم ولی کامنت ها ثابت هستند

 

3 -  ترجیح می دهم که انرژی که در جهت تولید کد بسیار شفاف و گویا صرف شود که در همان ابتدای کار نیازی به کامنت ها نداشته باشد کامنت های نادرست همیشه بدتر از نبود کامنت هستند کامنت های نادرست و فریبنده و گمراه کننده هستند 

 

4 - کد تنها  منبع دقیق  برای اطلاعات است که بنابراین گاهی اوقات کامنت ها در کد نیاز است اما تا جایی که امکان دارد  باید انرژی صرف کنیم تا اون هارو به حداقل برسونیم   

 

5 - کد خوانا و شفاف با کامنت کم به مراتب بهتر از کد پیچیده با تعداد کامنت های زیاد است به جای صرف وقت برای نوشتن کامنتی  که توضیح دهنده کدی است که شما ایجاد کرده اید زمان و انرژی را صرف نوشتن کد تمیز کنید

 

6 - در بسیاری از موارد کاری را که می خواهید در کامنت بگویید به سادگی و با ایجاد یک تابع می توان بیان کرد

 

7 -  کامنت هایی که جنبه حقوقی یا معرفی نویسنده رو دارند بهتر هستش که بیام بیرون و در یک فایل قرار بگیرند

 

8- کامنتی کامنت خوب هست که راهی برای نگارش آن پیدا نکنید 

 

9 - ما بعضی مواقع می توانیم بیایم و یکسری اطلاعات اولیه را تبدیل به یک کامنت کنیم  مثل این که مثلا تابع زیر چه چیزی رو برای ما بازگشت می دهد و یا این که بیایم و توضیح هدف کنیم از خطوط زیر که این کد ها هدفشون چی هستش

 

10 - بعضی مواقع ما کدی داریم که  از یک کتابخونه یا ماژولی هستش که نمی تونیم بیایم و تغیرش بدهیم در این مواقع استفاده از کامنت برای شفاف سازی بهتر کد می تونه مفید باشه گرچه این راه به ندرست باید استفاده بشه و ما حدالمقدور باید یک کد خوانا و تمیز بنویسیم

 

11 - گاهی اوقات ما وقتی در کدمون مجبور می شیم مثلا یک کدی رو غیر فعال کنیم یا مثلا کدمون در یک حالت خاص یک ایرادی داره بهتر هستش بیایم و یک کامنت به عنوان هشدار برای عواقب کار براش بنویسیم

 

12 - کامنت های Todoکارهایی هستند  که برنامه نویسان فکر میکنند که باید انجام شود اما در حال حاضر به دلایلی نمی توانند انجام شوند این ممکن است یک یادآوری یا حذف یا یک امکان منسوخ شده یا درخواست از یک نفر دیگر برای بررسی یک مشکل باشد ممکن است درخواستی برای فکر کردن به یک نام بهتر یا یادآوری برای تغیر دادن یک وابستگی  در یک رویداد برنامه ریزی شده باشد Todo ها هرچیز دیگری باشد اما بهانه ای برای قرار دادن کد بد در سیستم نمی باشد

فایل پیوست

emad ta

توسط

emad ta

12 اردیبهشت 00

0
حذف شده

13 -  نوشتن یک کامنت در کد صرفا به خاطر اینکه احساس میکنید باید بیاد و نوشته بشه یا اینکهفرایند بع آن نیاز دارد نوعی پیچاندن کار به حساب می اید اگر تصمیم به نوشتن کامنت گرفته اید زمان لازم  زمان لازم را صرف کنید که مطمئن شوید این بهترین کامنتی هست که می توانید بنویسید

 

14 - از نوشتن کامنت های تکراری پرهیز کنید وقتی کد به خوبی خوانا هست لزومی به کامنت گزاری نیست خود کد گویای همه چیز هستش 

 

15 - از نوشتن کامنت های نویز که هیچ اطلاعات جدیدی رو ارائه نمیکنند پرهیز کنید 

 

16 - زمانی که می توانید از یک تابع یا یک متغیر استفاده کنید از کامنت استفاده نکنید  

 

17 - استفاده از نشانگر های موقعیت یا اصطلاحا کامنت های  موقعیت  تنها در مواقعی بیاید و استفاده کنید که مزایای قابل توجه ای داشته باشند  

// Action ////////////////////////////////

 

18 - وقتی ما یک سری توابع طولانی و تو در تو داریم میتونیم بیایم و یکسری کامنت برای محکم کاری یا درک بهتر بزاریم اما باز اولویت با کوتاه کردن و کوچک کردن توابع هستش 

 

19 - کامنت های ما نباید از لحاظ متنی اونقدر طولانی باشند که طرف از خودنشون خسته شه و باید از اصل خلاصه نوشتن هم استفاده کنیم

فایل پیوست

emad ta

توسط

emad ta

13 اردیبهشت 00

1
حذف شده

 فصل 2  نام گزاری ها

-------------------------------

 

1 - انتخاب نام های خوب زمان بر است اما در آینده زمان بیشتری به نسبت وقتی که برای انتخاب نام صرف می کنید برای شما ذخیره میکند پس مراقب نام های انتخابی خود باشد و زمانی که نام های بهتری یافتید آن ها را تغیر دهید 

 

2 - نام یک متغیر یا تابع یا یک کلاس باید به تمام سوالات بزرگ پاسخ دهد این نام باید به شما بگوید که چرا اصلا چنین چیزی وجود دارد چ کاری انجام میدهدو چگونه باید از آن استفاده کرد اگر یک نام نیاز به به کامنت و توضیحات داشته باشد پس این نام به خوبی قصد و هدف را نشان نمی دهد 

 

3 - اجتناب از اطلاعات غلط برای ارجاع دادن به گروه حساب ها از account List  استفاده نکنید مگر آنکه واقعا یک لیست باشد یک لیست برای برنامه نویسان دارای معنا و مفهوم خاصی است اگر کانتینری که حاوی اکانت ها است یک لیست نباشد در نهایت باعث ایجاد نتایج غلط می شود بنابراین account Group accounts  گزینه های مناسب تری هستند

 

4 - سعی کنید در نامگزاری ها از نام هایی استفاده کنید که قابل جست و جو باشند و قابلیت سرج کردن رو داشته باشند همچنین از اجزای پیشوندی در نام گزاری ها استفاده نکنید چون ذاتا اسم عادت دارد که از پیشوند و پسوند رد بشه و خود کلمه اصلی رو بخونه

 

5 - برای استفاده از حلقه ها نام های i j k خوب هستند  همچنین سعی کنید از نامگزاری هایی که یک مفهوم خاصی که با اون موضوع ما تطابق نداره رو استفاده نکنید 

 

6 - کلاس ها و اشیا باید نام های اسمی داشته باشند این که نام یک کلاس فعل باشد این اشتباه هستش

 

7 - نام متد ها باید فعل یا یک اصطلاح فعلی باشد 

 

8- انتخاب نام فنی برای نامگزاری ها می تونه انتخاب مناسبی باشد

فایل پیوست

emad ta

توسط

emad ta

13 اردیبهشت 00

جلسه پیاده سازی accordion بهینه سازی کد