سلام?
توی رشته پست‌های قبلی راجب کدتمیز، چرایی نوشتن و اهمیت دادن به این موضوع، نظر بقیه برنامه‌نویسان درباره‌ی این موضوع و... صحبت کردیم(لینک پست قبلی بالای همین صفحه هست?) و فهمیدیم که عموباب میگه کدتمیز یعنی رعایت کردن کلی تکنیک ریز و کلی نکته که به جزئیات اشاره داره.
حالا توی این فصل میخوایم اولین نکته رو بررسی کنیم.
از اونجایی که نام ها و نامگذاری همیشه وجود دارند و ما همیشه در کد با آنها برخورد میکنیم، پس خیلی طبیعی است که به روش و اصول نامگذاری درست دقت کنیم و آنها را در کد هایمان به کار ببندیم.
در ادامه چند قانون ساده برای ایجاد یک نام خوب رو بررسی میکنیم و به اختصار هرکدوم رو توضیح میدیم:
نام‌ها باید بیانگر نیت ما باشند و این موضوع را باید جدی بگیریم. درسته که انتخاب نام های خوب زمان‌بر است، اما در آینده زمان بیشتری به نسبت وقتی که برای انتخاب نام‌ها صرف میکنیم برای ما ذخیره میشود. پس باید حواسمان به نام‌های انتخابی باشد و زمانی که نام‌های بهتری پیدا کردیم آنها را تغییر دهیم.
نام یک متغیر، تابع و یا یک کلاس باید به تمام سوالات بزرگ پاسخ بدهد. این نام باید به ما بگویید که چرا چنین چیزی وجود دارد، چه کاری انجام میدهد و چگونه باید از آن استفاده کرد. اگر یک نام نیاز به کامنت و توضیحات داشته باشد پس این نام به خوبی قصد و هدف را نشان نمیدهد.
برنامه‌نویسان باید از دادن سرنخ‌های غلطی که مفهوم کد را پنهان میکند، اجتناب کنند. باید از نوشتن کلماتی که معنای معتبر اونها، به جای معنای مورد نظر ما درک میشن اجتناب کنیم. به عنوان مثال برای ارجاع دادن به گروه حساب‌ها، از accountList استفاده نکنیم چون در برنامه نویسی کلمه list دارای معنا و مفهوم خاصی است و بجاش میتونیم از اسم‌های accountGroup, bunchOfAccounts یا accounts استفاده کنیم.
باید مراقب نام‌هایی باشیم که تفاوت خیلی کمی باهم دارند تا موقع استفاده به اشتباه نیفتیم. در محیط‌های کدنویسی امروزی که بسیار مدرن هستند و هنگام تایپ قسمتی از اسم، بقیه آنرا به ما پیشنهاد میدهد، این مشکل خودش رو به وضوح نشون میده که نام‌هایی که تشابه زیادی باهم دارند و براساس حروف الفبا مرتب شده‌اند، برنامه‌نویس را موقع استفاده در شک می اندازند.
برنامه‌نویسان زمانی که کد را فقط برای راضی نگه داشتن کامپایلرها و مترجمان می‌نویسند، برای خودشان مشکل ایجاد میکنند. برای مثال چون شما نمی‌توانید از نام‌های یکسان برای نوع‌های مختلف در دامنه یکسان استفاده کنید، ممکن است که وسوسه شوید یکی از نام‌ها را به دلخواه تغییر دهید.
اینکه شماره‌های سری اضافه کنیم(مثلا a1وa2) یا از کلمات نویز(مثل: the,a,an,of,...) برای متمایز کردن نام‌ها استفاده کنیم و حتی کامپایلر از شما خطا نگیرد کافی نیست. این موارد باید از نظر مفهوم نیز متفاوت باشند.
انسان‌ها در تلفظ کلمات خوب عمل میکنند. بخش مهمی از مغز ما به مفهوم کلمات اختصاص داده شده است و کلمات به وسیله‌ی تعریفشان قابل تلفظ هستند. این یک ضعف است که از بخش بزرگی از مغزمان که در زبان گفتاری پیشرفت کرده است استفاده نکنیم. پس نام‌های خود را قابل تلفظ کنید. به عنوان مثال نام متغیر genymdhms برای نگه داشتن مقدار generation date, year, month, day, hour, minute, second ، از لحاظ تلفظی مشکل دارد.
نام‌های تک حرفی و ثابت‌های عددی مشکل خاصی دارند. زیرا پیدا کردن آنها در متن کاری بسیار مشکل است. پیدا کردن رشته MAX_CLASSES_PER_STUDENT در متن بسیار راحتر از پیدا کردن ۷ است!
نتیجه این کار به طور همزمان، هم سبب ایجاد مشکل میشود و هم از جستجو برنامه‌نویس در برنامه جلوگیری میکند. به همین ترتیب برای برنامه‌نویسی که ممکن است نیاز به جستجو داشته باشد انتخاب نام e برای یک متغیر، یک انتخاب ضعیف و غیرحرفه‌ای است. ترجیح شخصی من این است که از نام‌های تک حرفی فقط و فقط به عنوان متغیرهای محلی درون تابع‌های کوچک استفاده شود.
به اندازه کافی روش های کدگزاری وجود دارد و نیازی نیست تعداد بیشتری را به کار خودمان اضافه کنیم. نوع کدگزاری یا محدوده اطلاعات در نام‌ها صرفا یک بار اضافی به کدگشایی اضافه میکند. منطقی به نظر نمی‌آید که برنامه‌نویس دیگری را مجبور کنیم که علاوه بر یادگیری کدهای مربوط به کار خود، عملیات کدگشایی را برای کدهای ما نیز یادبگیرد.
نشانه‌گذاری مجارستانی(یک نوع نشانه‌گذاری قدیمی است که نوع متغیر، در نام متغیر به صورت مختصر آورده میشود) در قدیم کاربردهای خواستی داشته است و به برنامه‌نویس در تشخیص نوع متغییر، کلاس یا ... قبل از کامپایل کد کمک میکرد. اما امروزه با وجودIDE های پیشرفته و زبان‌های سطح بالا با قابلیت وابستگی اشیایٔ به نوع، این نشانه‌گذاری اضافه‌کاری محسوب میشه و با پایین آمدن قابلیت خوانایی کد، بیشتر کار را سخت میکند.
شما نیازی ندارید که متغیرها را با پیشوند مثلا m_ نامگذاری کنید. کلاس‌ها و توابع باید به اندازه کافی کوچک باشند که شما نیاز به انجام چنین کاری نداشته باشید. علاوه بر این برنامه‌نویسان سریع یادمیگیرند که پیشوند یا پسوند را نادیده بگیرند تا بخش معنادار نام را ببینند و در نهایت پیشوندها نامریٔی میشوند و یادآور کدهای قدیمی تر میشوند.
نام‌هایی که شما انتخاب میکنید، نباید ذهن خواننده را به سمت نام‌هایی که از قبل میشناخته است هدایت کند. مثلا در یک حلقه شمارنده معمولا ممکن است از i یا j یا k استفاده شود، اگرچه دامنه کوچک است و هیچ نام دیگری با آن تشابه ندارد. این به این علت است که نام‌های تک حرفی برای نامگذاری حلقه‌ها یک روش سنتی است. با این حال در اکثر زمینه‌های دیگر نام‌های تک حرفی، انتخاب ضعیفی بشمار می‌آیند.
یک تفاوت بین برنامه‌نویس هوشمند و برنامه‌نویس حرفه‌ای این است که برنامه‌نویس حرفه‌ای میداند که وضوح (Clarity) همه چیز است. حرفه‌ای ها از قدرت خود بهره میگیرند و کدی ارایٔه میدهند که دیگران قادر به درک آن باشند.
کلاس‌ها و اشیا باید نام یا نام‌های اسمی، مانند Customer یا Account داشته باشند. نام یک کلاس نباید فعل باشد.
نام متدها باید فعل یا یک اصطلاح فعلی باشد مانند postPayment یا deletePage باشد.
نام‌هایی را انتخاب کنید که به وضوح درگیری ذهنی بیشتری ایجاد میکنند. سادگی در کد اغلب به شکل گفتارها یا به صورت عامیانه ظاهر میشود. به عنوان مثال از whack به معنای kill برای متد استفاده نکنید. چیزی که دقیقا مدنظرتان است را بگویید.
از یک کلمه برای یک مفهوم انتزاعی استفاده کنید و با آن تا آخر کنار بیایید. به عنوان مثال این گیج کننده است که fetch،retrieve و get را به عنوان روش‌های معادل در کلاس‌های مختلف در نظر بگیریم.
از یک کلمه یکسان برای استفاده در دو هدف مختلف اجتناب کنید. استفاده از یک اصطلاح یکسان برای دو ایده متفاوت اساسا باعث تشابه میشود. اگر از قانون «هرکلمه به ازای هر مفهوم» استفاده کنید، می‌توانید کلاس‌های موجود را به پایان برسانید.
به یاد داشته باشید کسانی که کد شما را می‌خوانند برنامه‌نویس خواهد بود. بنابراین پیش بروید و از قوانین علوم کامپیوتر، نام الگوریتم‌ها، قوانین ریاضی و ... استفاده کنید.
زمانی که دیگر از نام دامنه به دلیل تکراری شدن نمیتوان در نام‌گذاری‌ها استفاده کرد، باید از نام دامنه مسئله مورد نظر استفاده کنید. حداقل برنامه‌نویسی که کد شما را نگه‌داری میکند، میتواند معانی را از متخصص دامنه بپرسد.
نام‌های کمی وجود دارند که معنی‌دار هستند، در عوض شما باید نام‌هایی را در متن برای خواننده خود قرار دهید که این کار از طریق نامگذاری کلاس‌ها توابع یا فضاهای نام انجام میشود. وقتی هیچ راه دیگری ندارید، پیشوند نام ممکن است به عنوان آخرین راه‌حل لازم باشد. البته راه‌حل بهتر این است که کلاسی برای مفهوم موردنظر ایجاد کنید تا حتی کامپایلر هم متوجه شود که این مفاهیم متعلق به یک مفهوم بزرگتر می‌باشد.
قسمت‌های اضافی به نام اضافه نکنید مخصوصا پیشوندهایی بلا استفاده! در یک برنامه فرضی با نام «Gas station deluxe» یک ایده بد این است که هر کلاس را با GSD پیشوند کنید. صادقانه به شما بگوییم که شما در حال کار در برابر ابزار خود هستید. شما G را تایپ میکنید و با لیست پیشنهادی طولانی از IDE خود روبرو میشوید. آیا این عاقلانه است؟
نام‌های کوتاه‌تر به طور کلی بهتر از بقیه هستند. تا زمانی که نام‌ها واضح‌اند، هیچ نامی به نام‌هایتان اضافه نکنید.
سخترین چیز در مورد انتخاب نام‌های خوب، این است که نیاز به یک مهارت توصیفی خوب و یک پس‌زمینه فرهنگی مشترک دارد. این یک مسئله تدریسی است نه یک مسئله فنی، مدیریتی، یاتجارتی. به عنوان یک نتیجه بسیاری از مردم یادنگرفته‌اند که اینکار را خوب انجام دهند. این فصل به این موضوع تأکید دارد و نکته‌ها و تکنیک‌هایی را بیان میکند که با رعایت آنها میتوان گفت این قسمت از تمیز نویسی کد را با موفقیت پشت سر گذاشته‌اید.
تا قسمت بعدی خدانگه‌دار
(آیدی اینستاگرام من: hossein._.no1)
