قوانین طلایی نام گذاری متغییر ها (variables) !!!

! توجه کنید که این نوشته یک ترجمه هستش که لینکش رو در پایین میذارم !

در ابتدا به تعریف 10 دستور برای نامگذاری متغییر ها می پردازیم :

1. نام متغییر ها خاص باشند !
2. از کلمات غیر ضروری و من در آوردی استفاده نکنید !
3. از اختصارات مبتکرانه ( مبتکرانه از نگاه خودتون ینی، نه کسی که میخواد کد رو بخونه ) استفاده نکنید!
4. برای نام گذاری از کلمات یک زبانی (زبان انسانی) استفاده کنید که افراد تیم با آن آشنا هستند مثلا اگر در تیم همه انگلیسی صحبت می کنن شما از کلمات اسپانیای استفاده نکنید !
5. از کلمات خودساخته استفاده نکنید !!! ( این خیلی مهمه )
6. نوع متغییر رو توی نام متغییر وارد نکنید ( هر چیز جای خودش ) مثلا فرض کنید بگن افشین باریک ( میدونم خیلی بی ربط بود ولی خواستم یه طوری لپ مطلب رو ادا کنم )
7. سعی کنید از کلماتی که واضح و مشخص نیستن استفاده نکنید مگر اینکه طی یک پروتکل برای تیم مشخص شده باشه که چی به چیه.
8. کلمه ای رو انتخاب کنید که در صحبت بیشتر گفته میشه مثلا در صحبت ترجیح داده میشه بگن Transform تا اینکه بگن GetTransformation
9. از یک سینتکس استوار استفاده کنید
10. و قانون اخر می خواد بگه قوانین رو بشکن اگر جایی نیاز بود بشکنی !!!!

این دستورات برای نام گذاری کافی به نظر میاد، اما بعد از گذشت مدتی من به این نتیجه رسیدم که به یک روند برای نامگذاری متغییر ها رسیدم، به یک روند یا روش که می تونم ازش برای نامگذاری دقیق هر چیزی استفاده کنم !

به روشی که من میدونستم چیه ولی نمیدونم چطور میدونستم !!! ( اینارو دارم از زبون اون بنده خدایی میگم که نوشته ).

 byte[] ctnt = docClass.Content(dID);

بعد از کمی آزمایش و خطا، میشه یه جورایی اسامی نام گذاری کد بالارو به این صورت جایگزین کرد:

byte[] content = documentRepository.GetContent(docID);

اما اگر یکی ازم سوال کنه که 'چرا اسمای متغییر هاتو تغییر دادی به این اسامی خاص' بهترین توضیحی که من میتونم بدم اینه که ' زیرا این تنها مواردی هستن که درست به نظر میرسند' که این ناخوشایند و راضی کننده نیست !!!!

اما الان، من به این سوال میتونم پاسخ بدم،‌اما نه با 10 قانون بلکه تنها با یک قانون : " قانونی طلایی نام گذاری متغییر ها " .

قانون طلایی :

این قانون طلایی چی میتونه باشه ؟ اون میتونه فقط این باشه :

اسامی متغییر ها باید در حد امکان یک توصیفی باشند مختصر از چیزی که میخوایم.

من صدای شما خوانندگان عزیز را می شنوم که میگید هنوزهم موارد دیگه وجود داره برای نامگذاری،‌که من میگم بله درست میگید ! نامگذاری فقط یک هنر و مهارت هست ، چیزی که ما فقط با تمرین و عدم موفقیت به دست میاریمش. اما این قانوم گرچه مفیده ولی همه شرایط رو در بر نمیگیره. ( یک خط رو نتونستم درکش کنم برای ترجمه ببخشید !)

پس با این وجود این وجود مثال قبلی رو در نظر بگیرید :

byte[] ctnt = docClass.Content(dID);

با توجه به قانونی که گفته شد ما می تونیم نتیجه گیری کنیم که :

1. نام ctnt مخفف یا مختصر شده اما توصیفی نیست. این یک کلمه نیست تنها مجموعه ای از حروف هست که تفسیرشونم راحت نیست. ما باید این کلمه رو با نامی جایگزین کنیم که دقیقا اون چیزی رو که نشون میده توصیف هم بکنه.
2. نام docClass خیلی عمومی هستش. خب حالا این کلاس چیه ؟ یک سرویسه؟ یک ریپازیتوریه؟ یک مپرره؟ یا چیز دیگه ؟ خب ما هیچکدوم ازینارو نمیتونم بگیم. خب ما باید این نام رو با نامی جایگزین کنیم که به خواننده بگه این کلاس برای چه کاری استفاده شده و چه کاری رو میخواد انجام بده.
3. متد Content هم خوانا هست هم مختصر شده اما به اندازه کافی توصیفی نیست. این متد میخواد چه کاری رو با محتوا انجام بده؟ آیا میخواد اونو بازیانی کنه؟ یا آپدیته کنه؟ یا حذفش کنه؟ بازم هیچکدوم ازینارو نمیتونم به طور قطع برای این نام بگیم. ما باید این نام رو با یک نام فعال تر جایگزین کنیم، چیزی که دقیقا کاری که این متد انجام میده رو بیان کنه.
4. متغییر dID مخفف و مختصر هست و قابل فهم نیست. به احتمال زیاد شناسه سند خاص هستش، نمی توان بدون اینکه وارد کد شد فهمید که برای چه استفاده شده. ما باید این نام رو با یک توصیف بیشتر که قابل فهم تر باشه جایگزین کنیم.

بنابراین با استفاده از قانون نامگذاری طلایی، و نکاتی که در بالا ذکر شد،‌می تونیم به یک مثال بهتر برسیم :

byte[] content = documentRepository.GetContent(docID);

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

و اما خلاصه موارد بالا :

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

حالا اگر شما دوستان هم تجربه ها یا قوانین خاص خودتونو دارین که کد هارو تمیز تر و قابل خوانا تر میکنه به اشتراک بذارید.

متن بالا ترجمه ای از این لینک می باشد. ( میدونم خوب ترجمه نشده و مشکل داره برای همین ببخشید اگر وقتتونو گرفتم دوستان )

موفق و پیروز باشید ...