چرا نام گذاری درست در برنامه نویسی اینقدر حیاتی هست؟

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

به نامگذاری سطر پایین لطفا دقت کنید.

int n;

برنامه نویسی که به این شکل متغیر تعریف میکند چند دلیل دارد.

• تازه وارد دنیای برنامه نویسی شده و هنوز قوانین ابتدایی را نمیداند!
• خیلی عجله دارد و در حال تست قسمتی از کار هست!
• چنین رفتاری در دنیای کاری او تبدیل به یک عادت شده هست!

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

به نحوی نامگذاری در سطر پایین دقت کنید.

public List<Users> HemeroListkon(){}

public List<Users> BaGorohListkon(int shomareGoroh){}

نامگذاری متد به فارسی در مرحله اول به نظر میرسد خوانا هست و مشکلی ندارد!!

ایراد فینگلیش دادن اسم متغیر ها چیست؟ فکر کنید ما میخواهیم در پروژه از طریق رفلکشن متدهایی که کارشون واکشتی دیتا از دیتابیس هست رو کش بکنیم و یا در قسمت یونیت تست پروژه بعد اینکه یک ورژن جدید دادیم میخایم به جنگینز یا TFS بگیم فقط توابعی که کارشون واکشی دیتا هست رو تست و دیپلوی بکن چون نمیخام کل پروژه بیلد بکنم. در چنین حالتی فانکشن های واکشی ما هیچ معلفه مشابهی ندارند و باید یکی یکی همه رو بنویسیم و بعد چند روز اگر دوباره تابع جدیدی نوشتیم اونم بریم دستی اضافه کنیم و راه رو هم برای خطا هم کد کثیف هموار میکنم!! ولی اگر مثل کد زیر تعریف میشدند

public List<Users> GetList(){}

public List<Users> GetByCategory(int categoryId){}

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

زبان مشترک یا Common language: اگر پروژه رو گروهی در حال توسعه دادن باشیم من از کلمه Get استفاده میکنم و دوستم از Fech ،این یعنی مشکلات ... فقط قسمت کشف عملکرد فانکشن ها یه معمایی میشه!! به همین دلیل چه تنهایی چه گروهی برای نامگذاری متغیرها و فانکشن ها باید قوانین تعریف و استفاده کرد تا وارد حیطه کد کثیف نشویم.

شاید الان بگید چرا به این موضوعات یونیت تست و یا کش وارد شدیم!! دلیلش اینه ما هر روز داریم خودمون رو آپدیت میکینم و پروژه بزرگ تر میشود و الان شاید آسپکت پروگرمینگ رو ندونی، یونیت تست ننویسی ولی بعد چند سال وقتی به بحث آسپکت پروگرمینگ و یا جنکینز و یونیت تست آشنا شدین، میگید من اون موقع از اسم گذاری فارسی استفاده کردم و فکر میکردم کارم درسته ولی ای کاش اینکارو نمیکردم ...

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

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

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

به سمپل زیر دقت کنید.

همانطور که می بینید توسعه دهنده از اسم های مخفف استفاده کرده و همین امر باعث شده برای DataTable , DateTime از یک مخفف استفاده بکنه یکی رو dt دیگری رو Dt استفاده کرده، در همین چند خط کد ساده به دلیل اینکه از اسم گذاری کوتاه و اشتباه استفاده شده خوانایی کد رو نزدیک به صفر کرده.

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

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

نامگذاری در زبان ها. مثلا در سی شارپ متد ها پاسکال کیس نوشته میشود ولی در جاوا کمل کیس نوشته میشود. بنابراین باید قوانین نامگذاری یک زبان را بخوانیم تا زبان مشترک با دیگر برنامه نویسان اون زبان رو داشته باشیم و یا برای پروژه و سازمان یک سند نامگذاری بنویسم و به بقیه اعضای تیم بگیم که مطابق سند نامگذاری هارا انجام بدهند.

پاسکال کیس Pascal Case: یعنی حروف اول کلمات بزرگ باشند مثل GetUsers

کمل کیس Camel Case: یعتی اولین کلمه با حروف کوچک و کلمات بعدی حروف اولشون بزرگ باشند مثل getUsers

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

C# Naming Conventions

Java Naming Conventions

python Naming Conventions

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