چگونه یک کد تمیز بنویسیم. خلاصه‌ای از کتاب Clean Code

به کدی تمیز میگن که به راحتی توسط هرکسی که کد رو میخونه، قابل فهم باشه. یکی از مشکلاتی که در هنگام نگاه به کد و بررسی آسیب پذیری دارم اینه که اصلا نمیفهمم چی نوشتن و چکار کردن. کتاب clean code نوشته رابرت مارتین، یکی از بهترین کتاب‌ها در زمینه نوشتن کد خوانا و تمیز است. در این پست قصد دارم خلاصه ای از این کتاب رو به صورت تیتر وار بگم. اگه نیاز به جزئیات بیشتر داشتید می‌تونید به کتاب اصلی مراجعه کنید.کد تمیز چیست؟کد خوب یا بد، کدی هست که بشه خیلی زود فهمیدش و در موردش صحبت کرد.یک کد خوب باید کوتاه، مفید، قابل خوندن، ساده و بدون تکرار باشه.یک کد خوب می‌تونه ارزش کسب و کار یک بیزینس رو بالا ببره.قواعد کلیاز یک قرارداد استاندارد پیروی کنید.سادگی همیشه بهترِ. تا جای ممکن پیچیدگی را کاهش بدید.از قانون پیشاهنگی پیروی کنید. یعنی کد رو تمیز‌تر از آنچه که تحویل گرفتید، تحویل بدید.همیشه دنبال دلیل اصلی یک مشکل باشید.قوانین نامگذارینام‌ها توصیفی و قابل فهم باشه. نام‌ها قابل تمایز از هم باشن.از نام‌های قابل تلفظ استفاده کنید.از نام‌های قابل جستجو استفاده کنید.اعدادی که در کد زیاد استفاده می‌شوند (اعداد جادویی)، مثل ۳.۱۴ را با ثابت‌ها جایگزین کنید.از نام‌هایی با کدینگ‌های جورواجور، اظافه کردن پیشوند یا اطلاعاتی در مورد نوع متغیر، اجتناب کنید.سعی کنید نام، مشخص کننده دامنه سیستم، زمینه و مشکلاتی که برای حل آن ایجاد شده، باشد.قوانین توابعکوچک باشند. حداکثر ۲۰ خطفقط یک کار انجام دهند.از نام گذاری توصیفی استفاده کنید.هرچه تعداد پارامترها کمتر باشه، بهترِ. حداکثر ۲ تا. اگر احساس می‌کنید بیشتر نیازه باید توجیح داشته باشید.از پارامترهای پرچم(بولین) که شرایط خاصی را در تابع نشان می‌دهند اجتناب کنید. با این کار نشون میدید تابع شما بیش از یک کار انجام میده. به جای آن تابع را به چند تابع مستقل تقسیم کنید به گونه ای که بدون پرچم هم قابل فراخوانی باشند.توابع باید کاری رو انجام دهند و چیزی رو برگردونن.قوانین توضیحاتسعی کنید توضیحات کوتاهی در مورد خودتون تو کد قرار بدید.یکی از عمده ترین دلایل قرار دادن توضیحات به دلیل بد بودن کد است.اگر همش به این فکر می‌کنی که چه توضیحاتی باید بنویسی، کدت نیاز بازسازی داره.توضیحات، یک کد بد رو نجات نمیده.توضیحات بیش از حد نباشه.از اضافه کردن مواردی که آشکار هستن و نیاز به توضیحات بیشتری ندارند اجتناب کنید.از قرار دادن توضیحات در جلوی براکت بسته اجتناب کنید.کدی را که قصد استفاده ندارید، تبدیل به کامنت نکنید. فقط حذفش کنید.از توضیحات برای شرح هدفتون استفاده کنید.به منظور شفاف کردن کد، از توضیحات استفاده کنید.توضیحات زمانی مفیدن که در جای درست قرار بگیرند.به عنوان یک هشدار برای نشان دادن عواقب استفاده از کد، از توضیحات استفاده کنید.قوانین طراحیداده‌های قابل پیکربندی را در بالاترین سطح قرار بدید.سعی کنید تا جای ممکن از چندریختی (polymorphism) به جای if/else و switch/case استفاده کنید.کدهایی که مولتی ترد اجرا می‌شوند رو جدا کنید.از پیکربندی‌های غیرضروری و اضافی که فهم کد را سخت میکنه، اجتناب کنید.از تکنیک تزریق وابستگی استفاده کنید. یعنی به جای استفاده مستقیم از وابستگی‌های خارجی در درون کلاس، آنها را به کلاس تزریق کنید.از قانون دمیتر پیروی کنید. این قانون میگه یک کلاس فقط باید وابستگی‌های مستقیم خودش رو بشناسه.ساختار کدمفاهیم را به صورت عمودی از هم جدا کنید.کدهایی که مرتبط با هم هستند، زیر هم قرار گیرند.متغیرها را نزدیک به جایی که قصد استفاده از آنها را دارید، تعریف کنید.توابعی که به هم وابسته هستند باید در کنار هم تعریف شوند.توابعی که شبیه هم هستند باید در کنار هم تعریف شوند.توابع را بر حسب اهمیت و استفاده، از بالا به پایین قرار بدید.تعدا کاراکترها در خط‌وط را محدود کنید. ۱۲۰ تا کاراکتر در هر خط.عملگرها، پارامترها و کاما را با فاصله از هم جدا کنید. قوانین تورفتگی رو تقض نکنید.ساختمان داده و اشیاءساختار داخلی را پنهان کنید.از ساختمان‌های داده‌های ترکیبی (نیمی اشیاء، نیمی داده) خودداری کنید.کپسوله سازی (Encapsulate) و کلاس‌هاای انتزاعی (abstract class) را به درستی پیاده سازی کنید.ساختارها باید کوتاه باشند.ساختارها باید یک کاری را انجام بدن.کلاس پایه نباید هیچ اطلاعی از کلاس‌های مشتق شده داشته باشد.بهتر است چندین تابع مختلف تعریف کنیم تا اینکه یک تابع داشته باشیم که در شرایط مختلف رفتار متفاوتی داشته باشد.بهتر است به جای استفاده از توابع استاتیک از توابع غیر استاتیک استفاده کنید.تست‌هابه ازای هر تست یک assert تعریف کنید.تست باید سریع باشد.مستقل باشد.قابل تکرار باشد.کد بد بو (Code smells)در انتها، کد شما نباید بد بو باشه. موارد زیر ویژگی‌های یک کد بد بو را نشون میده: ایجاد تغییرات در نرم افزار سخت و یک تغییر کوچک باعث ایجاد تغییرات بعدی به صورت آبشاری میشه. با یک تغییر کوچک، نرم افزار در خیلی از جاها شکننده میشه.شما نمی‌تونید بخشی از کد را به خاطر ریسک‌ها و خطرات آن در پروژه‌ دیگری استفاده مجدد کنید.پیچیدگی زیاد داره.تکرار زیاد داره.درک کردن کد دشوار است.منبع با اندکی تغییر