آموزش طراحی وب

۱۵ نکته برای افزایش خوانایی کد های پروژه

خوانایی کد های پروژه یکی از موضوعات مهم در دنیای برنامه نویسی است، اولین چیزی که باید به عنوان یک توسعه دهنده یاد بگیرید این است که چگونه کد های پروژه تان را خواناتر کنید. البته خیلی از افراد با این ذهنیت که “کسی جز خودم کد ها را نمی بیند” استاندارد های لازم را رعایت نمی کنند، اگر شما هم همین ذهنیت را دارید بد نیست به این جمله مشهور از استیو جابز توجه کنید.

آن طرف یک کمد دیواری که رو به دیوار است را هم می بایست به گونه ای طراحی و رنگ آمیزی کرد که اگر روزی کسی اساس کشی داشت و پشت آن کمد دیواری را مشاهده کرد، شوکه نشود!

قضیه در برنامه نویسی هم دقیقاً به همین صورت است. درست است که احتمالاً اسکریپت هایی که می نویسیم قرار است فقط و فقط توسط خودمان ویرایش شوند، اما فرض را بر این بگذاریم که ممکن است روزی پیش بیاد که یک برنامه نویس دیگر قرار است تا کدهای ما را ویرایش کند و آنجا است که اهمیت کدنویسی اصطلاحاً “تمیز” خود را به خوبی نشان خواهد داد.

۱ – کامنت گذاری و مستند سازی

زمانی که محیط های توسعه یک پارچه (IDE) به وجود آمد موجب شد تا کامنت گذاری نقش مهمی در خوانایی کدهای پروژه ایفا کند. تصویر زیر به خوبی اهمیت کامنت گذاری را به نمایش می گذارد.

readable_code_1
همیشه فرض را بر این می گیرند که شما ۱۰۰۰ خط کد نوشته اید! اما من به شما تخفیف می دهم، فرض کنید ۵۰۰ خط کد نوشته اید اگر قرار باشد هربار جهت بررسی تشابه نام یک تابع بین خط ها اسکرول کنید طبیعتا زمان زیادی از دست خواهید داد. از طرفی با کامنت گذاری در هر خطی از برنامه که باشید متوجه کاربرد تابعی که به کار رفته خواهید شد.

۲ – دندانه گذاری خطوط به طور هماهنگ

هرچند این موضوع کاملا واضح است و اکثر شما می دانید که دندانه گذاری نقش مهمی را در کد نویسی تمیز ایفا می کند. به هر حال تکرار این موضوع با ذکر چند مثال بد نیست !

۱. حالت اول

۲. حالت دوم

۳. حالت سوم

من درحال حاضر از حالت اول استفاده می کنم. اما چندان مهم نیست که از کدام سبک استفاده می کنید. درواقع هیچ قانونی برای انتخاب “بهترین” وجود ندارد ولی در پروژه های گروهی معمولا افراد درباره سبک دندانه گذاری و مستند سازی با یکدیگر گفتگو می کنند. (برگرفته از مجموعه داستان های باور نکردنی!)

۳ – آنچه که عیان است چه حاجت به بیان است !

یک ذهنیت غلط دیگر که در بین توسعه دهندگان دون پایه رواج دارد این است که کامنت گذاری باعث افزایش حجم فایل می شود.

پ ن: هرگونه اشاره عبارت دون پایه به خوانندگان این مقاله تکذیب می شود. لطفا مزاحم نشوید!

بگذریم، درواقع منشا اصلی این داستان به مثال زیر برمی گردرد:

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

به جهت اینکه این موضوع را کاملتر درک کنید لطفا مثال زیر را با مثال بالا مقایسه کنید.

مثال فوق یک نمونه عالی از کامنت گذاری صحیح است درواقع زمانی به کامنت گذاری نیاز داریم که عملکرد یک تابع یا یک بلوک/بلاک دستوری (مجموع چند خط کد) نامفهوم باشد.

۴ – گروه بندی دستورات

اغلب اوقات، مجموعه چند دستور منجر به انجام یک عملیات (task) می شود پس برای برای اینکه مجموعه دستورات را با یکدیگر اشتباه نگیریم بهتر است آنها را گروه بندی کنید. برای این کار کافیست بین آنها چند فاصله ایجاد کنید.

در هنگام گروه بندی، کامنت گذاری را فراموش نکنید!

۵ – پیروی از یک شیوه نامگذاری

پیروی از یک شیوه نامگذاری به خوانایی دستورات کمک می کند و یک امر الزامی است. درضمن! فراموش نکنید که در مستندات پروژه نام شیوه نامگذاری مورد استفاده را درج کنید. من از نگارش شتری  (camel case – کملکیس) پیروی می کنم و برایتان چند مثال می زنم.

۱. نامگذاری کلاس ها

 ۲. نامگذاری توابع

اینگونه توصیف شده است که باید همیشه از حروف کوچک استفاده کنیم، پس صرف نظر از نمونه های زیر اشتباه محسوب می شود.

 ۳. نامگذاری متغیر ها

نامگذاری متغیر ها تقریبا شبیه به نامگذاری متد در کلاس هاست و متغیر های تک حرفی فقط برای حلقه ها مورد استفاده قرار می گیرند.

 ۴. نامگذاری ثابت ها

نامگذاری ثابت ها دقیقا مثل نامگذاری متغیر هاست با این تفاوت که باید تمامی حروف بزرگ باشند.

۵. NULL,FALSE,TRUE

همه کلمات کلیدی را بزرگ بنویسید.

۶. عملگر های منطقی

استفاده از عملگر || به جای OR توصیه نمی گردد به این دلیل که در برخی دستگاه ها مشخص نیست و ممکن است با ۱۱ اشتباه گرفته شود. اما می توانید به جای AND از && استفاده کنید.

۶ – پیروی از یک سبک کامنت نویسی

من توصیه می کنم برای درج توضیحات طولانی از سبک DocBlock استفاده کنید و یا به جای درج توضیحات طولانی در فایل پروژه، به پاراگراف مربوط به آن در فایل مستندات پروژه (readme.md) اشاره کنید.

۷ – پرهیز از تو درتویی عمیق

تودرتویی بیش از حد نه تنها موجب افزایش خوانایی نمی شود، بلکه چشم انسان را نیز آزار می دهد.

البته مقدار تو در تویی قانون خاصی ندارد (من حد اکثر ۴ فاصله ایجاد می کنم) ولی باز هم انتخاب با شماست.

 ۸ – خطوط را محدود کنید

چشمان ما قادر به دنبال کردن خطوط بسیار طولانی نیست پس شدیدا پیشنهاد می کنم از نوشتن خطوط طولانی (خصوصا هنگام نوشتن کوئری) پرهیز کنید.

 ۹ – دسته بندی فایل ها و پوشه ها (مدیریت پروژه)

ازنظر فنی شما باید کل پروژه را در یک فایل بنویسید. اما زمانی که می خواهید یک تابع را ویرایش کنید این مسئله به یک کابوس بزرگ تبدیل می شود و از نظر خوانایی هم اصلا استاندارد نیست.

یک ذهنیت غلط دیگر این است که مدیریت پروژه به معنای ساختن یک پوشه به نام INC (یا در نهایت امر include) است. و در آن فایل های مربوط به دیتابیس را جداگانه  و سایر دستورات را در یک فایل کلی به نام function ذخیره کنیم.

برای پرهیز از این عمل و افزایش سرعت کارها پیشنهاد می کنم شروع به یادگیری یک فریمورک php کنید (به عنوان مثال همین فریمورک laravel که در ماهنامه آموزش داده می شود) و یا از سبک دسته بندی سایر فریم ورک ها پیروی کنید.

codeigniter

تصویر فوق مربوط به سبک مدیریت پروژه در فریمورک CodeIgniter است.

۱۰ – نوشتن دستورات SQL با حروف بزرگ

پایگاه داده یکی از بزرگترین قسمت های هر پروژه است، اگر شما درحال نوشتن یک سطر از دستورات sql هستید بهتر است آنها را با حروف بزرگ بنویسید که خوانایی بیشتری داشته باشند. هرچند رعایت این امر به صورت پیش فرض الزامی است.

 ۱۱ – جداسازی داده ها از کد ها

در دنیای برنامه نویسی تحت وب منظور از “داده ها” همان صفحات html هستند، اما این قانون در تمامی زبان های برنامه نویسی ثابت است و بسته به محیط آن “داده ها” شکل متفاوتی دارند.

برای جداسازی شدیدا پیشنهاد می شود از یک فریمورک که طبق اصول MVC پایه گذاری شده است استفاده کنید.

۱۲ –  تناوب نحوی درون پوسته ها

همیشه لازم نیست “جداسازی داده ها از کد ها” را انجام دهیم، گاهی اوقات مسئله چندان بزرگ نیست و برای حل آن یا باید از یک موتور ساخت قالب استفاده کنید و یا شیوه تناوب نحوی درون پوسته ها را یاد بگیرید (درمورد آن بعدا مقاله ای خواهم نوشت) فعلا مثال زیر را به عنوان بیعانه قبول کنید.

۱۳ – شی گرایی در مقابل رویه گری

هرچند همیشه شی گرایی بهترین گزینه برای نوشتن دستوراتی خوانا تلقی می شود اما به این معنی نیست که شما باید برنامه نویسی به سبک رویه ای را فراموش کنید. گاهی وقت ها واقعا نیازی به شی گرایی نداریم.

و درضمن، الان نوشتن یک برنامه به سبک شی گرا یک افتخار محسوب نمی شود (چون یک باید / should است) پس جسارتا دفعه بعدی که درباره ویژگی های پروژه تان مستند سازی می کنید، عبارت “کد نویسی به سبک شی گرا” را حذف کنید.

۱۴ – پروژه های متن باز را بررسی کنید

همیشه پروژه های متن باز را بررسی کنید، سعی کنید از دستورات نوشته شده سر در بیاورید. به سبکی که آنها برای مستند سازی استفاده می کنند توجه کنید

open_source

۱۵ – کایزن را سرلوحه کارتان قرار دهید

پس از جنگ جهانی دوم، ژاپنی ها مفهومی تحت عنوان Kaizen را ابداع کردند که این مفهوم تک کلمه ای توانست آینده ژاپن و بالتبع دنیا را دستخوش تغییرات شگرفی کند. اگر بخواهیم این واژه ژاپنی را به صورت تحت الفظی به زبان فارسی ترجمه کنیم، با معادلی همچون “بهبود مستمر” رو به رو خواهیم شد (واژه kai به معنی “تغییر یا اصلاح” می باشد و zen هم به معنی “خوب” است.)

kaizen

مکتب کایزن در مقابل فلسفه اکثر کشورهای غربی قرار دارد که در آن گفته می شود “تا زمانیکه چیزی خراب نشده است، نیازی به تعمیر آن نیست” و این در حالی است که کایزن دقیقاً عکس این را عمل می کند به این شکل که “حتی اگر در کار خود مشکلی ندارید، برای بهبود و تغییر مثبت آن تلاش کنید چرا که اگر این کار را نکنید، از آنهایی که این سیاست را دنبال می کنند عقب خواهید ماند.”

اگر بخواهیم از امروز کایزن را در کدنویسی به کار بندیم، با کار خیلی دشواری رو به رو نخواهیم بود زیرا همانطور که پیش از این توضیح دادیم، کایزن به معنی تغییرات شگرفت و یکباره نیست بلکه کایزنی کردن کدهای خود بدان معنا است که به مرور زمان سعی کنیم تمیز تر، اصولی تر، قابل ویرایش تر و به طور کلی حرفه ای تر کدنویسی کنیم.

کلام پایانی

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

تهیه شده در مدرسه مجازی ایرانیان

محمد هادی اعظمی

من محمد هادی اعظمی، برنامه نویس و توسعه دهنده نرم افزار هستم. چهار سال است که به طور جدی در این زمینه فعالیت میکنم و با مجموعه های مختلف تحت عناوینی مثل طراح وب، توسعه دهنده نرم افزار و توسعه دهنده وب کار کرده ام.

دیدگاه ۵

  • سلام خیلی خوب بود.استفاده کردیم.ولی گاهی ابزارهایی برای فشرده کردن کدها پیشنهاد میشه تا حجم فایل پایین بیاد که در این صورت کدها فشرده شده و نظم شون رو از دست میدن.منظورم فاصله گذاریها هست.

    • بله حرف شما کاملا درسته ولی فشرده سازی رو آخر سر انجام میدن ! من بیشتر برای اینکه سبک کد نویسی افراد از اسپاگتی در بیاد این مقاله رو نوشتم.

  • خیلی خوب بود! اولا که خیلی استفاده کردم و دوما لحن نوشته اتون رو هم خیلی پسندیدم ، چیزی که توی مقالات ایرانی کمتر دیده میشه ! کمی حس شوخ طبعی!!!

آیا سوالی دارید؟

پنل کاربران

بستن
*
*

نظرسنجی

به کدام دسته موضوعی علاقه مند هستید؟

آخرین پرسش و پاسخ ها

اموزش تصادفی