تابستون داره تموم میشه ها، فرصت‌ها محدودن کلی آفر جذاب در کمپین تابستون🔥👇
۰ ثانیه
۰ دقیقه
۰ ساعت
۳ emad ta
خلاصه ای از مطالب کتاب Clean Code اثر رابرت مارتین
جامعه جاوا اسکریپت ایجاد شده در ۱۱ اردیبهشت ۱۴۰۰

فصل 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 انجام دهیم و در کل قاعده کلی استفاده از اون‌ها باید به این شیوه باشند که این‌ها فقط یک بار ظاهر می‌شوند  و برای ایجاد اشیا چندریختی استفاده می‌شود و در پشت رابطه ارث بری پنهان می‌شودتا بقیه سیستم‌ها اون هارو نبینند

فصل 4 کامنت ها 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

emad ta ۱۲ اردیبهشت ۱۴۰۰، ۱۴:۱۱

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

 

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

 

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

 

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

 

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

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

 

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

 

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

emad ta ۱۳ اردیبهشت ۱۴۰۰، ۰۸:۳۴

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

emad ta ۱۳ اردیبهشت ۱۴۰۰، ۱۱:۱۳