بنابراین اگر می‌خواهید سریع پیش بروید، اگر می‌خواهید سریع کار را انجام دهید، اگر می‌خواهید نوشتن کدتان آسان باشد، خواندن آن را آسان کنید. – رابرت سی مارتین
معمولاً دو نوع برنامه نویس باهوش و حرفه ای وجود دارد. هر دوی آنها می توانند کار را انجام دهند اما تفاوت های زیادی بین این دو وجود دارد. حرفه ای ها می دانند که وضوح پادشاه است. آنها از قدرت خود برای نوشتن کدهای تمیز استفاده می کنند که دیگران بتوانند آن را بفهمند و با نوشتن کد تمیز روی آن کار کنند. اما کد پاک دقیقاً چیست؟ ویژگی های آن چیست و چگونه می توان کد تمیز نوشت؟ اینها سوالاتی در ذهن من بود که وقتی شروع به خواندن Clean Code نوشته رابرت سی مارتین کردم و خوشحالم که این کتاب اصلاً من را ناامید نکرد. این کتاب نکات کلیدی زیادی برای کدهای پاک دارد و من فکر می کنم هر برنامه نویسی باید آن را به خصوص در ابتدای کار خود بخواند.
در این مقاله یاد خواهیم گرفت
-
نام متغیرها باید هدف آن را نشان دهد و نباید شامل نوع داده باشد
-
نام کلاس و تابع باید به ترتیب یک اسم و فعل باشد
-
توابع باید فقط یک کار را انجام دهند و تعداد آرگومان ها باید حداقل باشد
-
تا حد امکان از اظهار نظر خودداری شود
-
بخش هایی از کد که به هم مرتبط شده اند باید در کنار یکدیگر قرار گیرند
-
کد باید به گونه ای فرمت شود که هنگام خواندن آن، چشمک زدن حداقل باشد
تمام کدهای این مقاله به زبان پایتون نوشته شده است، بنابراین اگر با زبان آن آشنایی ندارید ممکن است برای شما کمی انتزاعی باشد.
ویژگی های Clean Code؟
رابرت سی مارتین با نام مستعار عمو باب از برخی برنامه نویسان بسیار باتجربه و سرشناس پرسید که نظر آنها در مورد کد پاک چیست. طبق آنها در اینجا تعدادی از ویژگی های کد تمیز آورده شده است.
من دوست دارم کد من ظریف و کارآمد باشد. منطق باید ساده باشد تا پنهان کردن اشکالات سخت شود. کد پاک یک کار را به خوبی انجام می دهد. – بیارن استروستروپ(مخترع C++)
کد پاک را می توان توسط توسعه دهنده ای غیر از نویسنده اصلی آن خواند و تقویت کرد. دارای آزمون واحد و پذیرش می باشد. اسامی معنی دار دارد – دیو توماس
کد پاک ساده و مستقیم است. کد پاک مانند نثر خوش نوشته خوانده می شود – *گریدی بوچ* (نویسنده تجزیه و تحلیل شی گرا و طراحی با کاربردها)
بنابراین، اگر من این ویژگی ها را بیان کنم، کد تمیز باید باشد
-
زیبا: باید ساده و خوانا باشد. هنگام خواندن آن باید لبخندی به لبتان بیاورد.
-
متمرکز شده است: هر تابع/ماژول باید a را نشان دهد با اراده نگرش. فقط باید روی انجام یک کار تمرکز کند.
-
تست ها: اگر تست نداشته باشد، هر چقدر هم که ظریف/خوانا باشد، تمیز نیست.
نوشتن کد پاک
نام معنی دار
اگر نامی نیاز به نظر داشته باشد، آن نام قصد آن را آشکار نمی کند. – عمو باب
اسامی مهم هستند زیرا هدف را آشکار می کنند. ساختن نام‌های خوب و معنی‌دار زمان میبرد، اما باور کنید ارزشش را دارد زیرا باعث صرفه‌جویی در زمان می‌شود که باید بعداً آن را بخوانیم/ مرور کنیم.
نام متغیر
باید ماهیت آن را بدون هیچ اظهارنظری توصیف کند و اگر اینطور نیست، نام آن تغییر کند. یعنی
نوع داده نباید بخشی از نام متغیر باشد حتی اگر در قرارداد کدگذاری زبان مجاز باشد. به خصوص در پایتون در زمان تعریف متغیر، ما نوع داده را تنظیم نمی کنیم. اگر نوع داده یک متغیر را در نقطه ای تغییر دهیم، مشکل ایجاد می کند زیرا باید آن را با نوع داده جدید جایگزین کنیم. بیایید نگاهی به مثال زیر بیاندازیم
تغییر متغیر فوق به float بسیار سخت خواهد بود زیرا ما باید آن را در هر کجا که از آن استفاده کرده ایم جایگزین کنیم. با این حال، در *نماد مجارستانی* مجاز است اما اکنون استفاده از آن توصیه نمی شود و مایکروسافت نیز این نماد را توصیه نمی کند. (ارجاع)
نام متغیرها باید تلفظ شوند. همانطور که عمو باب گفت اگر نمی توانید آن را تلفظ کنید، نمی توانید بدون اینکه شبیه یک احمق به نظر برسید، درباره آن بحث کنید. “خب، اینجا روی “bee cee arr three cee enn tee” (bcr3cnt) یک “pee ess zee kyew” (pszq) int داریم، می بینید؟”
یک نام نیز باید قابل جستجو باشد، زیرا نام‌های طولانی‌تر بر نام‌های کوتاهتر ترجیح داده می‌شوند. همچنین، یک نام کاراکتر نباید برای یک محدوده بزرگ استفاده شود. فقط باید در یک محدوده کوتاهتر مانند یک تابع/حلقه کوچک استفاده شود.
نام تابع و کلاس
نام تابع باید یک فعل باشد و همچنین باید عمل را همراه با مقدار، مانند، نشان دهد extract_age، delete_user_info. *از طرف دیگر، نام کلاس نباید فعل باشد. این باید یک اسم یا یک عبارت اسمی باشد. به عنوان مثال * مشتری، حساب و ثبت آب و هوا.
با اضافه کردن زمینه های غیر ضروری کار را برای خود سخت نکنید. هر کلاس/تابع را با زمینه پیشوند قرار ندهید، مگر اینکه نشان دهنده زمینه متفاوتی باشد. به عنوان مثال در برنامه ای از “Green Pizza Hut”، قرار دادن پیشوند هر تابع/کلاس با “gph” بسیار بد خواهد بود زیرا تعداد زیادی کاراکتر اضافی وجود خواهد داشت. نام های کوتاهتر تا آنجا که واضح هستند بهتر هستند.
ناز بودن
اگر بامزه هستید، عالی است که برای شما خوب است، اما لطفاً کد را زیبا نکنید و آن را حرفه ای نکنید. من می دانم که نامگذاری یک متغیر به نام حیوان خانگی یا شخصیت مورد علاقه خود بسیار زیبا به نظر می رسد، اما چگونه می توان فهمید که چیست؟حباب ها” یا “دکستر“.
هنگام نامگذاری متغیرها، توابع یا کلاس های خود از کلمات عامیانه استفاده نکنید. مثلا استفاده نکنید نام تجاری() به معنی kill().
یک کلمه در هر مفهوم
یک کلمه برای یک مفهوم انتخاب کنید و به آن بچسبید. به عنوان مثال، ما نباید از *get، retrieve، استخراج *و *fetch به عنوان نام تابع *برای مفهوم یکسان کلاس های مختلف استفاده کنیم. یادآوری اینکه کدام کلاس دارای نام تابعی است بسیار دشوار خواهد بود. به همین ترتیب، داشتن *Manager، Controller *در پایگاه کد نیز گیج کننده است زیرا هر دو هدف یکسانی دارند.
کارکرد
توابع باید یک کار را انجام دهند. آنها باید آن را به خوبی انجام دهند. آنها فقط باید این کار را انجام دهند. عمو باب
اندازه در توابع مهم است، اولین قانون یک تابع این است که باید کوچک باشد و سپس باید کوچکتر از آن باشد.
یک چیز را انجام دهید
اگر یک تابع بیش از یک کار را انجام دهد، هیچ مزیتی برای نوشتن یک تابع وجود ندارد. از آنجا که هدف اصلی نوشتن توابع، تجزیه یک مفهوم بزرگتر به مجموعه ای از مراحل در سطح بعدی انتزاع است. توابع نباید به اندازه کافی بزرگ باشند تا ساختارهای تودرتو را نگه دارند. همچنین سطح تورفتگی یک تابع نباید بیشتر از یک یا دو باشد. خواندن و درک عملکرد را آسان تر می کند.
عملکرد بالا، با وجود اینکه خیلی طولانی نیست، بیش از یک کار را انجام می دهد. بلوک قبل از حلقه باید یک تابع جداگانه باشد.
عمو باب روشی را برای دانستن اینکه یک تابع بیش از “یک کار” انجام می دهد اشاره کرد این است که اگر بتوانید تابع دیگری را با نامی از آن استخراج کنید که صرفاً بیان مجدد اجرای آن نباشد.
استدلال ها
برای یک تابع نباید بیش از سه آرگومان وجود داشته باشد. تعداد ایده آل آرگومان ها باید صفر باشد. استدلال های بیشتر قدرت مفهومی بیشتری می گیرد. تعداد کمتری از آرگومان ها نوشتن موارد تست را آسان تر می کند.
استدلال های پرچم زشت است. ارسال یک بولی به یک تابع یک عمل واقعا وحشتناک است. بلافاصله امضای تابع را پیچیده می کند و با صدای بلند اعلام می کند که این تابع بیش از یک کار را انجام می دهد. اگر پرچم درست باشد یک کار را انجام می دهد و اگر پرچم نادرست باشد.
نظرات
هیچ چیز نمی تواند به اندازه یک نظر خوب مفید باشد. هیچ چیز نمی تواند به اندازه یک اظهار نظر قدیمی که دروغ و اطلاعات نادرست را تبلیغ می کند، مخرب باشد. – عمو باب
نظرات همیشه شکست هستند. ما آنها را داریم زیرا همیشه نمی توانیم بفهمیم که چگونه بدون آنها خودمان را بیان کنیم، اما استفاده از آنها دلیلی برای جشن گرفتن نیست. هدف از اظهار نظر نباید توضیح مقصود باشد. ما یک ماژول می نویسیم و می دانیم که گیج کننده و بی نظم است. ما می دانیم که این یک آشفتگی است. پس با خود می گوییم “اوه، بهتر است من نظر بدهم!” نه! بهتره تمیزش کنی!
در کد زیر دو راه وجود دارد. یک کد درهم و برهم با یک نظر برای توضیح آن و دیگری کد تمیزی است که خودش را بدون هیچ نظر توضیح می دهد.
بنابراین، وقتی می‌توانید از متغیر/تابع استفاده کنید، از نظرات استفاده نکنید.
متأسفانه ما، برنامه نویسان، به طور واقع بینانه نظرات را حفظ نمی کنیم. نیاز تغییر می‌کند و کد نیز تغییر می‌کند، بخشی از آن از اینجا و آنجا حرکت می‌کند، اما نظر آنجا می‌ماند و باعث ایجاد آشفتگی و سوء تفاهم می‌شود. هیچ کد نظری یا نشانگر موقعیتی نباید وجود داشته باشد. بسیار نادر است که نشانگرهای موقعیت منطقی باشند که عملکرد خاصی را با هم جمع کنند، اما به طور کلی، آنها باید حذف شوند.
نمونه ای از موقعیت ساز در زیر آورده شده است.
*# Actions #######*
نظرات خوب
همه نظرات بد نیستند، گاهی اوقات لازم است نظر اضافه شود. به عنوان مثال به دلایل قانونی، خوب است نظرات مربوط به کپی رایت، نویسندگی را در ابتدای فایل اضافه کنید. همچنین منطقی است که هشداری در مورد عواقب و نظرات “به انجام” اضافه کنید.
گاهی اوقات یک نظر فراتر از اطلاعات مفید در مورد پیاده سازی است و دلیل نوشتن این کد را ارائه می دهد. به عنوان مثال، در مثال زیر توسعه دهنده دلیل اضافه کردن تاخیر دانلود را بیان می کند.
قالب بندی
قالب بندی کد مهم است. نادیده گرفتن آن بسیار مهم است و مهم است که با دین رفتار شود.
فایل منبع باید مانند یک مقاله روزنامه باشد. نام فایل باید ساده اما به اندازه کافی معنادار باشد تا به ما بگوید آیا در فایل درستی هستیم یا نه، درست مانند عنوان یک مقاله روزنامه. همانطور که شروع یک مقاله چکیده ای از مقاله می دهد و جزئیات هرچه وارد می شویم افزایش می یابد. به همین ترتیب، مفاهیم سطح بالا باید در بالای یک فایل باشند و جزئیات باید با پایین آمدن بیشتر شوند. عملکرد/جزئیات سطح پایین باید در انتهای فایل باشد.
قالب بندی عمودی
خطوط منطقی مشابه باید با یک خط خالی از خطوط دیگر جدا شوند. خط خالی یک نشانه بصری است که یک مفهوم جدید و مجزا را مشخص می کند.
درست مانند افزودن یک خط خالی مفاهیم را از هم جدا می کند، چگالی عمودی نیز دلالت بر ارتباط نزدیک دارد. خطوط کدی که کاملاً مرتبط هستند باید در کنار یکدیگر ظاهر شوند. زیرا اگر بخواهید زنجیره ای از وراثت را برای تعریف یک تابع/متغیر پیدا کنید و زمان و انرژی خود را صرف پیدا کردن و یادآوری مکان قطعات کنید، بسیار خسته کننده است.
اگر یک تابع دیگری را فراخوانی می کند، باید به صورت عمودی نزدیک باشند و در صورت امکان، فراخواننده باید بالای فراخواننده باشد. هر چه این وابستگی قوی تر باشد، فاصله عمودی کمتری بین آنها وجود دارد. این به برنامه یک جریان طبیعی می دهد. همچنین متغیرها باید تا حد امکان نزدیک به کاربردشان اعلام شوند.
قالب بندی افقی
ما از فضای سفید افقی برای مرتبط کردن چیزهایی که به شدت مرتبط هستند استفاده می کنیم و چیزهایی را که ارتباط ضعیفی دارند جدا می کنیم. ما اپراتورهای تخصیص را با فضای سفید احاطه می کنیم تا آنها را برجسته کنیم. فضاها این جدایی را آشکار می کنند. اما ما بین نام توابع و پرانتز افتتاحیه فاصله نمی گذاریم. این به این دلیل است که تابع و آرگومان های آن ارتباط نزدیکی با هم دارند.
در پایتون، ما مقایسه‌ها، عملگرهای ریاضی و بولی را نیز با یک فاصله قرار می‌دهیم، اما اگر چندین عملگر در یک خط وجود داشته باشد، عملگر را با اولویت پایین‌تر قرار می‌دهیم. یک مثال در زیر داده شده است.
خطوط زیر از “کد پاک” الهام گرفته نشده اند، بلکه این چیزی است که من در زندگی حرفه ای ام آموخته ام. در ابتدای کارم، اغلب توسط سرپرست تیم و افراد ارشد به من می گفتند که در حین بررسی کد، یک خط را به چند قسمت تقسیم کنم و بالعکس. در آن زمان من با این تقسیم و ادغام گیج شده بودم، اما بعد از آن، سرپرست تیم من این اثر “*چشمی” * را توضیح داد و سپس برای من منطقی شد.
اندازه یک خط باید نزدیک به طول خطوط همسایه آن باشد. به طوری که در هنگام خواندن کد باید تا حد امکان چشمک زدن به حداقل برسد. خواندن را بسیار آسان می کند.
به عنوان مثال در کد زیر، طول اندازه به خطوط همسایه خود نزدیک نیست
چشم در اینجا باید به حداقل برسد، کد refactored در زیر آورده شده است.
بنابراین، برای نتیجه گیری کل، در اینجا نکاتی را که شما از این موضوع دارید آورده ایم:
-
نام متغیر باید معنی دار، قابل تلفظ، قابل جستجو باشد و هدف آن را آشکار کند. نوع داده نباید بخشی از آن باشد.
-
نام کلاس ها باید یک اسم باشد و توصیف واضحی از چیزهای داخل آن داشته باشد.
-
نام توابع باید یک فعل باشد و فقط یک کار را انجام دهد و نباید خیلی طولانی باشد.
-
توابع باید دارای حداقل تعداد آرگومان باشند.
-
نظرات را می توان به عنوان آخرین راه مطلق برای توضیح آنچه می خواهید انجام دهید نوشت و باید به خوبی فکر کرد.
-
بخش هایی از کدهای مرتبط با یکدیگر باید در کنار یکدیگر قالب بندی شوند.
-
کد باید تا حد امکان کمتر چشم گیر باشد.
اگر سؤالی دارید یا دیدگاه خود را در این مورد دارید، لطفاً از طریق لینکدین با من در میان بگذارید.
کد نویسی پاک مبارک
