فرادرساشتباه های رایج کدنویسی که باید از آن ها اجتناب کرد — راهنمای کاربردی
انسان‌ها اشتباه می‌کنند، اما خطاهای زیادی وجود دارند که توسعه‌دهندگان می‌توانند و باید از آن‌ها اجتناب کنند. در صورتی که بتوانید از بروز اشتباه های رایج کدنویسی جلوگیری کنید، می‌توانید کد بهتر و تمیزتری حاصل خروجی کار شا خواهد بود.
این وضعیت نه تنها برای شما مفید است، بلکه به توسعه‌دهندگان دیگر که کد شما را بررسی می‌کنند هم کمک زیادی می‌کند. بنابراین این کار را نه فقط برای خودتان بلکه برای کمک به تیمتان نیز انجام می‌دهید. در ادامه برخی از اشتباه‌های رایج کدنویسی را معرفی کرده‌ایم که باید تلاش کنید از بروز آن‌ها جلوگیری کنید.
اجرای کارهای زیاد در یک تابع
بر اساس الگوی «مسئولیت منفرد»، یک تابع باید تنها مسئول انجام یک کار باشد. و منظور ما دقیقاً یک کار است. اغلب با تابع‌هایی مواجه می‌شویم که همه کارهای مرتبط با واکشی، پردازش و ارائه داده‌ها را یکجا انجام می‌دهند. تقسیم این وظایف، یک رویه برنامهنویسی مناسب تلقی می‌شود. تابعی که داده‌ها را واکشی می‌کند، تابعی که آن را پردازش می‌کند و تابعی که داده‌ها را نمایش می‌دهد، باید از هم جدا باشند.
دلیل اهمیت این موضوع که یک تابع روی یک دغدغه واحد متمرکز باشد، این است که موجب پایداری بیشتری در کد می‌شود. فرض کنید که در یک نمونه کد می‌خواهید داده‌ها را از یک API واکشی کنید. اگر تغییری در API حادث شود، برای مثال یک نسخه جدید موجود شود، در صورتی که پردازش کد بخشی از همان تابع واکشی داده‌ها باشد، خطر بزرگ‌تری متوجه کد خواهد بود. این وضعیت احتمالاً موجب بروز مشکلات در بخش ارائه داده‌ها نیز خواهد شد.
کدهای کامنت شده
برخی اوقات بلوک‌های کاملی از کد را می‌بینیم که شامل چندین تابع کامنت شده (منظور تابعی است که با استفاده از کاراکترهای کامنت از فرایند اجرایی حذف شده‌اند) هستند. هیچ کس نمی‌داند که آیا بخش کامنت شده کد همچنان با بقیه بخش‌های کد در ارتباط است یا نه. و با این حال هیچ کس هم جرئت نمی‌کند که آن بلوک کد را حذف کند. دلیل این که هیچ کس آن را حذف نمی‌کند، این است که فکر می‌کند ممکن است کس دیگری به آن کد نیاز داشته باشد.
کدی که کامنت شده را در اولین فرصت ممکن حذف کنید. حتی اگر این کد در بازبینی نهایی موجود نباشد، اگر کسی قصد داشته باشد از آن استفاده کند، همچنان در نسخه کنترل به آن دسترسی خواهد داشت.
نام‌گذاری غیر گویا برای متغیرها
رویه‌های مختلفی برای نام‌گذاری متغیرها معرفی شده‌اند. اما هر چه قدر هم تأکید شود، نمی‌تواند اهمیت انتخاب نام مناسب برای متغیرها را به روشنی مشخص سازد. در غالب موارد شما تنها فردی نیستید که روی یک پروژه کار می‌کنید. توسعه‌دهندگان دیگر باید بتوانند کد شما را به خوبی درک کنند. انتخاب نام مناسب ممکن است در آغاز فرایندی زمان‌بر باشد، اما حتماً زمانی بیش از آن چه صرف می‌شود را صرفه‌جویی می‌کند.
اعداد جادویی و رشته‌ها
در بخش قبلی در مورد اهمیت انتخاب نام‌های گویا برای متغیرها صحبت کردیم، در این بخش می‌خواهیم توضیح دهیم که چرا نباید مقادیر خاص را به متغیرها انتساب دهیم. این وضعیت به نام اعداد جادویی و متغیرها نیز نامیده می‌شود. ویکی‌پدیا عدد جادویی را به صورت زیر تعریف کرده است:
اعداد جادویی مقادیر یکتایی با معنی مشخص نشده یا رخداد مکرر هستند که می‌توان و باید به جای آن‌ها از ثابت‌های نام دار استفاده کرد.
به مثال قطعه کد زیر توجه کنید:
1for ($i = 1; $i <= 52; $i++) {
2 ...
3}عدد 52 در این مثال یک عدد جادویی است و هیچ کس نمی‌داند که چرا عدد 52 انتخاب شده است و نماینده چه چیزی است. چرا باید مقدار 52 باشد؟ چرا 64 نباشد؟ آیا منظور از 52 تعداد هفته‌های سال است؟
در این موارد بهتر است از ثابت‌های نام‌دار استفاده کنیم که گویاتر هستند:
1$cardDeckSize = 52;
2for ($i = 1; $i <= $cardDeckSize; $i++) {
3 ...
4}اینک همه می‌دانند که ما مشغول تعریف حلقه‌ای روی همه کارت‌های بازی در یک مجموعه کارت بازی هستیم. این وضعیت موجب می‌شود توسعه‌دهندگان دیگر نیز با زمینه موضوعی آشنا شوند. علاوه بر آن تغییر مقدار نیز آسان‌تر است، زیرا تکرار نشده است. این مقدار تنها یک بار در متغیر ذخیره شده است. اعداد جادویی اغلب چندین بار در محل‌های مختلف یک برنامه ظاهر می‌شوند که آن‌ها را مستعد بروز خطا می‌سازد.
همین وضعیت در مورد رشته‌ها نیز مصداق دارد:
1if (userPasswordIsValid($user, "6yP4cZ".$password)) {
2 ...
3}6yP4cZ چیست؟ به نظر می‌رسد یک رشته کاملاً تصادفی است.
1$salt = "6yP4cZ";
2if (userPasswordIsValid($user, $salt.$password)) {
3 ...
4}اکنون معنی آن مشخص می‌شود.
قالب‌بندی شلوغ کد
شلوغ کردن قالب‌بندی کد چیزی است که اغلب افرادی که تجربه برنامهنویسی زیادی ندارند، مرتکب می‌شوند. اغلب توسعه‌دهندگانی که چند سال تجربه برنامهنویسی داشته باشند، چندین تستر و یا دانشمند علوم داده را می‌شناسند که از قالب‌بندی شلوغ در کد خود استفاده می‌کنند. این وضعیت ناشی از کمبود تجربه است، مگر این که با یک زبان برنامهنویسی مانند پایتون کار کنید که اغلب این موارد را کاهش می‌دهد.
یکی از رایج‌ترین روش‌ها برای حل مشکل قالب‌بندی شلوغ استفاده از linter است. همه IDE-های مدرن امکان اصلاح این مشکل را دارند. برخی اوقات باید یک پلاگین نصب کنید و در برخی موارد دیگر این کار به صورت خودکار انجام می‌یابد.
هارد کد کردن
هارد کد کردن یک رویه توسعه نرم‌افزاری برای جاسازی داده‌ها مستقیماً در سورس کد یک برنامه یا دیگر شیءهای اجرایی است. این وضعیت مخالف به دست آوردن داده‌ها از منابع خارجی یا تولید آن به صورت آنی است. مقادیری که هارد کد شده باشند امکان پیکربندی ندارند، چون به صورت ثابتی تعریف شده‌اند. هارد کد کردن به عنوان یک ضد الگو یا دست‌کم رویه بد کدنویسی نگریسته می‌شود. چیزهایی که در اغلب موارد به هر دلیلی (در برخی موارد معتبر) هارد کد می‌شوند، شامل رمزهای عبور و محل فایل‌ها هستند.
یکی از حالت‌های رایج که اغلب می‌بینیم هارد کد شدن رمزهای عبور است، در مورد احراز هویت سرویس یا API اکسترنال است. این اطلاعات احراز هویت غالباً هارد کد می‌شوند هر چند رویه برنامهنویسی مناسبی محسوب نمی‌شود. اگر متوجه شدید که بخش زیادی از کد را هارد کد می‌کنید، باید کدنویسی خودتان را مورد بازنگری جدی قرار دهید، چون در اغلب موارد این بهترین روش برای حل یک مسئله نیست.
اگر این مطلب برای شما مفید بوده است، آموزش‌ها و مطالب زیر نیز به شما پیشنهاد می‌شوند:
- مجموعه آموزش‌های برنامهنویسی
- آموزش اصول و مبانی برنامه نویسی
- مجموعه آموزش‌های دروس علوم و مهندسی کامپیوتر
- ۱۰ نکته برای نوشتن کد بهتر و ساده‌تر — یک راهنمای جامع در خصوص کدنویسی مرتب
- ۱۲ ابزار مناسب برای بهبود مهارت های برنامه نویسی — راهنمای جامع
==
