اذر سورس 7 قانون برای نوشتن خوب کدها - اذر سورس

نوشتن کد خوب موضوعی است که توسعه دهندگان همه زبان های برنامه نویسی را درگیر کرده است. همه ما می دانیم که باید کد خوب بنویسیم اما این دقیقاً به چه معناست؟ برخی می گویند تا جایی که ممکن است کد کمتری بنویسید.

بعضی دیگر می گویند “کد تمیز” بنویسید و البته صحبت های دیگری که در این باب وجود دارد. در اینجا ۷ قانون برای نوشتن کد خوب و البته دلایل مرتبط با آن آمده است.

coding

قانون شماره ۱: رمان معمایی ننویسید

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

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

قانون شماره ۲: گاهی عملی بودن بهتر است از منظم بودن است

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

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

قانون شماره ۳: خطاها هرگز سکوت نمیکنند

وقتی خطایی به وجود آمد نباید آن را رها کنید. هرچه سریعتر برنامه خود را اشکال زدایی کنید و سعی کنید خطا را از سیستم حذف کنید. قبل از اینکه برنامه شما تکمیل شود باید خطایابی را انجام دهید. به عنوان مثال، کد زیر را مشاهده کنید.
نمونه کد
در ظاهر نمونه کد بالا بی خطر و بدون مشکل است. شما فرض می کنید که API شما همیشه کار خواهد کرد. اما همیشه در کار با API ها ممکن است خطایی ایجاد شود و پاسخی داده شود که قابل پیش بینی نباشد. معمولا چنین کدهایی یک کپی پیست کورکورانه از StackOverflow هستند. کد بالا را میتواند به روش متفاوتی پیاده سازی کرد:
کد
شما همیشه بدترین ها را فرض کنید، بنابراین خطاها را خود را در اولویت کاری خود قرار دهید.

قانون شماره ۴: کد خود را بفهمید، هرگز حدس نزنید

بسیاری از ما کپی کردن از Stack Overflow را به خوبی بلد هستیم و البته این کد نویسی نیست، شما فقط امیدوارید که هرچه شخص دیگری نوشته است به طرز جادویی برای شما کار کند.

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

قانون شماره ۵: توضیح آن آسان است

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

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

قانون شماره ۶: تا حد امکان از تودرتویی پرهیز کنید

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

قانون شماره ۷: در مواردی بهتر است از الگوهای طراحی استفاده کنید

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

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

صحبت پایانی

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

به این پست امتیاز دهید.
بازدید : 548 views بار دسته بندی : مقالات آموزشی تاريخ : 26 آگوست 2022 به اشتراک بگذارید :
دیدگاه کاربران
    • دیدگاه ارسال شده توسط شما ، پس از تایید توسط مدیران سایت منتشر خواهد شد.
    • دیدگاهی که به غیر از زبان فارسی یا غیر مرتبط با مطلب باشد منتشر نخواهد شد.