قراردادهای کدنویسی

قراردادهای کدنویسی مجموعه‌ای از دستورالعمل‌ها برای یک زبان برنامه‌نویسی خاص است که برای هر جنبه‌ای از یک برنامه نوشته شده در آن زبان، سبک برنامه‌نویسی، شیوه و روش‌های برنامه‌نویسی‌ای توصیه می‌کند. این قراردادها معمولاً شامل سازمان‌های فایل، دندانه گذاری‌ها، کامنت‌ها، تعریف کردن‌ها، بیانیه‌ها، فاصله سفید، قواعد نامگذاری، بهترین روش‌های برنامه‌نویسی، اصول برنامه‌نویسی، قانون‌های thumb در برنامه‌نویسی، بهترین شیوه‌های معماری، و غیره است. این موارد دستورالعمل‌هایی برای بهبود کیفیت ساختار نرم‌افزار هستند. به برنامه نویسان نرم‌افزار به شدت توصیه می‌شود که برای بهبود خوانایی code|سورس کد و آسان کردن نگهداری نرم‌افزار به دنبال این دستورالعمل‌ها بروند. قرادادهای کدنویسی، تنها برای نگهداری توسط انسان‌ها و بازبین‌های همتای یک پروژه نرم‌افزاری مناسب هستند. قراردادها می‌توانند در مجموعه ای از قوانین ثبت شده باشند که کل تیم یا شرکت از آن‌ها پیروی می‌کنند، یا ممکن است به صورت غیررسمی به عنوان عادت‌های برنامه‌نویسی معمول یک فرد باشد. قرادادهای کدنویسی توسط کامپایلرها اجرا نمی‌شود.

مهندسی نرم‌افزار

مهندسی نرم‌افزار فرایندی است که توسط آن پروژه مشخص و طراحی شده‌است. مهندسی نرم‌افزار برای موفقیت پروژه‌ها کاملاً بنیادی و ضروری است، خصوصاً اگر آنها، پروژه‌های بزرگی باشند. فرایند مهندسی نرم‌افزار، چیزی است که پروسهٔ کد زدن را تا زمان کامپایل موفق آمیز اجرا می‌کند. مهندسی نرم‌افزار خوب می‌تواند بین یک پروژه موفق (هم از نظر مالی و هم مهندسی) و پروژه ای که، در بدترین حالت، هنگام تحویل شکست می‌خورد، تفاوت ایجاد کند. مهندسی نرم‌افزار خوب هزینه‌های جاری را پایین می‌آورد و موفقیت در بازاریابی پروژه را به حداکثر می‌رساند.

کیفیت

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

استانداردهای کدنویسی

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

کاهش پیچیدگی

پیچیدگی یک فاکتور در مقابل امنیت است.
مدیریت پیچیدگی اصل اساسی زیر را شامل می‌شود: در طول پروژه توسعه سؤال اگر این پروژه با کمترین مقدار از کد مورد نیاز اجرا شود باید پرسید. اگر این کار را نکرده باشد، کار غیر ضروری انجام شده‌است و هزینه‌های غیر ضروری - هر دو از قبل و بعد از آن - متحمل شده‌اند.
پیچیدگی در مرحله طراحی طراحی می‌شود - چگونه پروژه‌ها معماری می‌شود - و در مرحله توسعه - چه کدام استفاده می‌شود. اگر برنامه‌نویسی پایه و ساده نگه داشته شود پیچیدگی به حداقل می‌رسد. اغلب این‌ها برنامه‌نویسی را به عنوان «فیزیکی» نگه می‌دارند - برنامه‌نویسی به شیوه ای بسیار مستقیم و بسیار انتزاعی نیست. این کد مطلوب را تولید می‌کند که به راحتی قابل خواندن و پیگیری است.
هر چه کد پیچیده‌تر باشد، احتمال باگ دار بودن کد بیشتر، پیدا کردن باگ، سخت‌تر و احتمال وجود باگ‌های پنهان بیشتر است.

بازآرایی (Refactoring)

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

خودکارسازی

قراردادهای کدنویسی اجازه می‌دهد تا اسکریپت‌های ساده یا برنامه‌هایی داشته باشیم که کار آن‌ها پردازش سورس کد برای اهدافی غیر از کامپایل کردن آن به یک برنامه قابل باشد. معمول این است که طول [خطوط] نرم‌افزار (خطوط سورس کد) را برای پیگیری پیشرفت پروژه یا تعیین خط نشانه ای برای پیاده تخمین‌های آینده پروژه بنا می‌کنند.
استانداردهای کدنویسی مداوم می‌تواند، به نوبه خود، اندازه‌گیری‌ها را مداوم تر کند. تگ‌های خاص داخل کامنت‌های سورس کد اغلب برای پردازش مستندات (documents) استفاده می‌شوند، دو نمونه قابل توجه جاواداک و doxygen هستند. ابزارها استفاده از مجموعه ای از برچسب‌ها (تگ‌ها) را مشخص می‌کنند، اما استفاده از آن‌ها در یک پروژه طبق قرارداد مشخص می‌شود.
قراردادهای کدنویسی نوشتن نرم‌افزار جدیدی که کار آن پردازش نرم‌افزار موجود است را ساده می‌کند. استفاده از تجزیه و تحلیل کد استاتیک به‌طور مداوم از سال ۱۹۵۰ افزایش یافته‌است. بخشی از رشد این طبقه از ابزارهای توسعه، نه تنها از افزایش بلوغ و کمال خود متخصصان (و تمرکز مدرن بر ایمنی و امنیت)، بلکه از ماهیت خود زبان‌ها نیز سرچشمه می‌گیرد.

فاکتورهای زبان

همه متخصصین نرم‌افزار باید با مشکل سازماندهی و مدیریت تعداد زیادی از دستورالعمل‌های گاهی پیچیده روبرو شوند. برای همه حتی کوچکترین پروژه‌های نرم‌افزاری، سورس کد (دستورالعمل‌ها) به فایل‌های جداگانه و اغلب بین بسیاری از دایرکتوری‌ها تقسیم می‌شوند. این برای برنامه نویسان طبیعی بود که توابع (رفتار) بسیار مرتبط را در یک فایل نگهداری کنند و فایل‌های مرتبط را در دایرکتوری‌ها مشترک جمع کنند. همان‌طور که توسعه نرم‌افزاری از برنامه‌های صرفاً رویه ای (مانند فورترن FORTRAN) به سمت ساختارهای شی گرا (مانند C ++) تغییر کرده‌است، این کار که کد را برای یک کلاس عمومی (public) در یک فایل واحد (قرارداد 'یک کلاس در هر فایل'). جاوا یک قدم فراتر رفته‌است - کامپایلر جاوا اگر بیش از یک کلاس عمومی در هر فایل پیدا کند. اروری را برمی‌گرداند.

یک قرارداد در یک زبان ممکن است یک پیشنیاز برای مورد دیگری باشد. قراردادهای زبان بر روی سورس فایل‌های شخصی نیز تأثیر می‌گذارند. هر کامپایلر (یا مفسر) مورد استفاده برای پردازش کد منبع منحصر به فرد است. قواعدی که کامپایلر برای سورس اعمال می‌کند استانداردهای مطلقی را ایجاد می‌کند. به عنوان مثال، کد پایتون بسیار دندانه محور تر از، مثلاً، Perl است، زیرا فاصله سفید (indentation) در واقع برای مفسر (interpreter) معنی دار است. پایتون از آکولاد استفاده نمی‌کند اما perl برای محدود کردن توابع استفاده می‌کند. تغییر در دندانه‌ها به عنوان تعیین‌کننده عمل می‌کند. Tcl، که از دستور زیر استفاده می‌کند مانند Perl یا C / C ++ برای تعریف توابع، موارد زیر را اجازه نمی‌دهد، هرچند که برای یک برنامه‌نویس C کاملاً معقول است: 
 set i 0
 while {$i < 10}
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }
 دلیل آن، این است که در Tcl، آکولادها تنها برای محدود کردن توابع استفاده نمی‌شود، همان‌طور که در C یا جاوا استفاده نمی‌شود. به‌طور کلی، آکولادها برای دسته‌بندی کلمات به یک آرگومان واحد استفاده می‌شوند. در TCL، کلمه while، دو آرگومان می‌گیرد، یک شرط و یک دستور. در مثال بالا، while آرگومان دوم خود یعنی دستورش را از دست داده‌است (زیرا Tcl هم از کاراکترهای خط جدید برای محدود کردن پایان یک دستور استفاده می‌کند).