خلاصه کتاب clean code – بخش اول

فهرست

جوگیرساختن مخاطب برای خواندن تا ته

اگر این فصل رو تا ته بخونید انتظار میره دیگه هیچ وقت اسم متغیرهاتون زشت و رکیک نباشه. هرکس کدتون رو دید بگه این انتخاب کننده اسامی متغیرهاش کیه؟ اینکه باید به چیا توجه کنیم موقع اسم گذاری و چه چیزهایی مارو به اشتباه میندازه. در ادامه خواهیم دید.فصل اول کتاب یسری چیز های کلی گفته بود و بیشتر انگیزه داده بود. فرض الان اینه که شما به اندازه کافی انگیزه دارید که کتابو بخونید پس بسملا .

فصل دوم – meaningful names

intension-revealing names

تمامی اسامی توی کد باید نشون دهنده‌ی یک معنی خاص باشن که باعث میشه همه موقع خوندن کد، ازجمله خودت، حس بهتری داشته باشید.

پس هرچی زودتر اون int a لعنتی رو پاک کن.

avoid disinformation

نباید متغیرها رو طوری انتخاب کنی که انقد شبیه به هم باشن که نشه تشخیصشون داد، مخصوصا جاهایی که شکل ظاهری کارکترها شبیه به همن مثل صفر و اٌ یا یک و اِل

احتمال اینکه انقد چیزای شبیه همو بچپونی توی یه اسم چقدره واقعا؟مجبوری ؟

meaningful distinction

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

product
productInfo
productData

واقعا اون مغزی که داره روزی ۸ ف…. ساعت در روز، منطق مزخرف پروژه رو پیاده میکنه بعیده که براش انتخاب چارتا اسم متفاوت از هم کار سختی باشه.

pronounceable names

وقتی خواستی اسم متغیر رو انتخاب کنی و داری بهش فکر میکنی، تصور کن میخوای اونو با اسم بلند فریاد بزنی .

اگر وقتی داری اینکارو میکنی بقیه فکر کردن کر و لال هستی ، پس اسم خوبی انتخاب نکردی. معمولا برای کول بازی میای مخفف میکنی یا حروف صدادار رو نمیذاری . نکن. مثل :

gndyhms : generation date year hour minutes second

use searchable names

مشکل اسامی تک حرفی و متغیر های ثابت عددی هستند که وقتی بخوای توی خروار ها کد دنبالشون بگردی و سرچشون کنی نمیتونی پیداش کنی.

پس متغیر های تک حرفی رو بذار کنار و یه چیز آدمیزادوار بنویس.
اگر هم توی منطق مسخرت داری از عددد خاصی استفاده میکنی بریزش توی متغیر ثابت سراسری که بعدا به خودت آفرین بگی.

avoid encoding

گذاشتن پسوند و پیشوند برای اسامی کار درستی به نظرنمیرسه. مثلا اینکه برای هر کتگوری از متغیر ها قبل یا بعدش یه چیزی بچسبونی .

مثلا:

فیلدهای کلاس رو قبلش یه m بذاری
بعد از اینترفیس ها i بذاری
بعد از توابع imp بذاری

درسته کشمش دم داره ولی تو این یه مورد بیخیال.

avoid mental mapping

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

حس شاعری و تشبیه ومراعات نظیر و استعاره مکنیه رو کنار گذاشته و به سمت رستگاری بروید .

شاید اونی که بعدا کد رو میخواد بخونه زیاد شعر و اینا بلد نباشه.

دوستی عزیزی وجود داشت که سرویسی نوشته بود اسمشو گذاشته بود میخانه، و به هر داده ای میگفت می، به یوزر ها سرمست میگفت و ادمین ساقی بود .

نکن 🙂

pick one word per one concept

از چنتا کلمه برای یک مفهوم استفاده نشه لطفا حتی اگر در کلاس های مختلف باشن. مثلا فقط از یکی از اینا میتونی استفاده کنی:

fetch
retrieve
get

بفرما، بشین، بتمرگ 😐

dont pun

این دقیقا برعکس قبلیه .

یعنی از یک کلمه برای دو منظور مختلف استفاده نکن.

آن یکی شیر است اندر بادیه
آن یکی شیر است اندر بادیه
طوطی و بقال ، مولوی

solution & problem domain names

اونی که قراره بعدا کدت رو بخونه خودش برنامه نویسی ناسلامتی، پس ازینکه از ادبیات علوم کامپیوتر توی اسامی استفاده کنی ترسی نداشته باش.

یا اگر میخوای از کلمات تخصصی اون پروژه خاص استفاده کنی اوکیه نگران ناخوانا بودنش نباش چون نفر بعدی هم باید در جریان پروژه باشه.

وبسایت: https://mrbug.ir

تلگرام: https://www.t.me/mrbug_ir
اینستاگرام: https://www.instagram.com/mrbug_ir

نویسنده مطلب: مسترباگ

منبع مطلب

محبوب ترین کتاب های چاپی

مجموعه ای از پرفروش ترین کتاب های چاپی را اینجا ببینید و با تخفیف ویژه خریداری کنید👇

مشاهده و خرید