کد نویسی تمیز با قوانین ساده.

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

توضیحات در کد (Comments in Code): قانون اصلی این است که از نوشتن کامنت خودداری کنید. ایده این است که اگر برای توضیح کاری که یک قسمت از کد انجام می‌دهد نیاز به کامنت دارید، خود کد به اندازه کافی واضح نیست. کد باید طوری نوشته شود که خود توضیحی (self-explanatory) باشد. متغیرها (variables)، متدها (methods) و سایر عناصر کد باید به گونه‌ای نام‌گذاری و ساختاربندی شوند که هدف آن‌ها بلافاصله آشکار باشد. وجود کامنت‌ها به عنوان یک "بوی بد کد (code smell)" در نظر گرفته می‌شود.

نام‌های معنادار (Meaningful Names): هنگامی که یک متغیر یا متد ایجاد می‌کنید، نام آن باید به وضوح هدف آن را نشان دهد. به عنوان مثال، به جای نامیدن یک متغیر arr، یک نام طولانی‌تر و توصیفی‌تر مانند userEmailList بهتر است. نام متدها نیز باید توصیفی باشند و به وضوح نشان دهند که متد چه کاری انجام می‌دهد. طول نام به اندازه وضوح آن مهم نیست.

کد استفاده نشده (Unused Code): هر کدی که استفاده نمی‌شود باید حذف شود. این شامل کد کامنت شده و داک بلاک‌های (doc blocks) غیر ضروری است. زبان‌های برنامه‌نویسی مدرن دارای ویژگی‌هایی مانند تایپ هینتینگ (type hinting) هستند که اطلاعاتی درباره انواع داده‌های مورد انتظار برای متغیرها و پارامترهای تابع ارائه می‌دهند، که نیاز به داک بلاک‌های گسترده را کاهش می‌دهد.

تست‌های واحد (Unit Tests): هنگام نوشتن کد، به خصوص برای شرایط مرزی (boundary conditions)، نوشتن تست‌های واحد بسیار مهم است. درباره نحوه رفتار کد فرضیاتی نداشته باشید. در عوض، رفتار آن را با تست‌ها تأیید کنید. به عنوان مثال، اگر انتظار می‌رود یک تابع یک رشته (string) را برگرداند، یک تست بنویسید تا اطمینان حاصل شود که واقعاً یک رشته و نه یک عدد صحیح (integer) را برمی‌گرداند.

شرایط مثبت (Positive Conditions): هنگام نوشتن عبارات شرطی (if statements)، به طور کلی بهتر است از شرط مثبت به جای شرایط منفی استفاده کنید. خواندن و درک شرایط مثبت معمولاً آسان‌تر است.

معماری کدنویسی (Coding Architecture): هنگام کار بر روی یک پروژه، مهم است که از معماری و استانداردهای کدنویسی تعیین شده پیروی کنید. اگر رهبر فنی (tech lead) قوانین یا الگوهای خاصی را مشخص می‌کند، به آن‌ها پایبند باشید. از ابزارهایی برای کمک به اجرای سازگاری معماری، مانند لینترها (linters) یا ابزارهای تجزیه و تحلیل ایستا (static analysis tools) استفاده کنید.

قراردادهای نامگذاری (Naming Conventions): قراردادهای نامگذاری واضح و سازگار برای خوانایی کد بسیار مهم هستند. نام‌هایی که برای متغیرها، متدها و کلاس‌ها انتخاب می‌کنید باید از دیدگاه شخصی که از کد استفاده می‌کند قابل فهم باشد.

اصول "DRY" و "KISS":

• برای خودت تکرار نکن "Don't Repeat Yourself (DRY)": این اصل بر اجتناب از تکرار کد تأکید دارد. اگر متوجه شدید که یک کد را در چندین مکان می‌نویسید، ایجاد یک کامپوننت (component)، تابع (function) یا ماژول (module) را در نظر بگیرید که قابل استفاده مجدد باشد. به عنوان مثال، در React، مفهوم کامپوننت‌ها بر اساس اصل DRY است.
• اسمش بده ولی کاری که میکنه خوبه :)) "Keep It Simple, Stupid (KISS)": این اصل توصیه می‌کند از پیچیدگی غیرضروری اجتناب کنید. کد خود را تا حد امکان ساده و سرراست نگه دارید. راه حل‌ها را بیش از حد مهندسی نکنید یا پیچیدگی را اضافه نکنید مگر اینکه واقعاً مورد نیاز باشد.

استثناها (Exceptions): به جای استفاده از کدهای بازگشتی (return codes) برای نشان دادن خطاها، از استثناها استفاده کنید. استثناها روشی قوی‌تر و ساختاریافته‌تر برای مدیریت خطاها ارائه می‌دهند. اگر یک تابع با خطا مواجه می‌شود، باید یک استثنا پرتاب کند (throw an exception) به جای اینکه یک مقدار خاص مانند null یا یک رشته خالی را برگرداند. از گرفتن استثناها (catching exceptions) و سپس برگرداندن null خودداری کنید، زیرا این می‌تواند خطای اساسی را پنهان کند.

بلوک‌های کد کوچک (Small Code Blocks): سعی کنید متدها و کلاس‌های خود را کوچک و متمرکز نگه دارید. اگر یک متد خیلی بزرگ شد، آن را به توابع کوچکتر و قابل استفاده مجدد تقسیم کنید. این کار باعث می‌شود کد راحت‌تر درک، تست و نگهداری شود.

"قانون پیشاهنگی (Boy Scout Rule)": این قانون بیان می‌کند که شما همیشه باید کد را "تمیزتر از آنچه که پیدا کرده‌اید" ترک کنید. هر زمان که روی یک قطعه کد کار می‌کنید، از فرصت استفاده کنید تا آن را ریفکتور (refactor) کنید، ساختار آن را بهبود بخشید و آن را خواناتر کنید. برای ریفکتور کردن کد نیازی به اجازه گرفتن ندارید. هر زمان که فرصتی را دیدید، این کار را انجام دهید.

بوهای بد کد (Code Smells): متن چندین "بوی بد کد" را ذکر می‌کند که نشان‌دهنده مشکلات احتمالی در کد شما هستند. در اینجا توضیح مفصل‌تری از هر کدام آورده شده است:

• تو در تویی عمیق (Deep Nesting): بلوک‌های کد تو در تو عمیق (یعنی تورفتگی بیش از حد) می‌توانند درک و خواندن کد را دشوار کنند. سعی کنید با استفاده از تکنیک‌هایی مانند بازگشت زودهنگام (early returns) یا استخراج کد به توابع جداگانه از تو در تویی عمیق اجتناب کنید.
• نامگذاری نامناسب (Inappropriate Naming): نامگذاری ضعیف نشانه‌ای است که کد ممکن است نامشخص یا ضعیف طراحی شده باشد. برای انتخاب نام‌های توصیفی و معنادار برای متغیرها، متدها و کلاس‌های خود وقت بگذارید.
• عبارات Switch: در حالی که عبارات switch گاهی اوقات ضروری هستند، اغلب می‌توان آن‌ها را با جایگزین‌های انعطاف‌پذیرتر و قابل نگهداری‌تر مانند چندریختی (polymorphism) یا الگوی استراتژی (Strategy pattern) جایگزین کرد.
• توده‌های داده (Data Clumps): این به موقعیت‌هایی اشاره دارد که در آن یک گروه از متغیرها به طور مکرر به عنوان پارامتر به متدهای مختلف ارسال می‌شوند. این نشان می‌دهد که متغیرها ارتباط نزدیکی دارند و باید در یک کلاس یا ساختار داده واحد کپسوله شوند.
• وسواس اولیه (Primitive Obsession): این اتفاق زمانی رخ می‌دهد که از primitive data types (رشته، عدد صحیح، بولی) برای نشان دادن مفاهیم دامنه استفاده می‌شود که بهتر است با کلاس‌ها یا enums سفارشی نشان داده شوند. به عنوان مثال، به جای استفاده از یک رشته برای نشان دادن یک رنگ، یک کلاس یا enum رنگ ایجاد کنید.
• وابستگی شدید (Tight Coupling): زمانی رخ می‌دهد که کلاس‌ها یا ماژول‌ها به شدت به یکدیگر وابسته باشند. این امر تغییر و استفاده مجدد از کد را دشوارتر می‌کند. با استفاده از تکنیک‌هایی مانند رابط‌ها (interfaces) و تزریق وابستگی (dependency injection) به دنبال کم کردن وابستگی (loose coupling) باشید.

انتقال پایگاه داده (Database Migrations): هنگام ایجاد انتقال پایگاه داده، از نام‌های زائد خودداری کنید. به عنوان مثال، در جدولی به نام files، ستونی به نام file_id زائد است. در عوض، از یک نام ساده‌تر مانند id یا یک نام خاص‌تر مانند service_id استفاده کنید.

نام توابع (Function Names): اطمینان حاصل کنید که نام توابع به طور دقیق هدف آن‌ها را منعکس می‌کند. یک تابع باید یک کار خاص را انجام دهد و نام آن باید به وضوح نشان دهد که آن کار چیست. از ایجاد توابعی که کارهای زیادی انجام می‌دهند یا نام‌های مبهم دارند خودداری کنید.

ساختار کلاس (Class Structure): اگر متدهای متعددی با پیشوند یکسان دارید، و داخل یک کلاس نیستید، ساخت یک کلاس را در نظر بگیرید و متدهای خود را به آنجا منتقل کنید.

منبع: کانال یوتیوب Parsclick -> قوانین برتر برای نوشتن کد تمیز