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

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

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

کاهش هزینه‌های نگهداری نرم‌افزار، بیشترین دلیل ذکر شده برای پیروی از قراردادهای برنامه‌نویسی زیر است. Sun Microsystems در مقدمه ای برای قوانین کدنویسی زبان برنامه‌نویسی جاوا، دلایل زیر را ارائه می‌دهد:[2]

معاهدات کد برای برنامه نویسان به دلایل مختلف اهمیت دارد:

  • ۴۰٪ -۸۰٪ از هزینه عمر یک قطعه نرم‌افزار به تعمیر و نگهداری می‌رود.
  • تقریباً هیچ نرم‌افزاری برای تمام عمر توسط نویسنده اصلی حفظ نشده‌است.
  • توافقنامه‌های کد، قابلیت خواندن نرم‌افزار را بهبود می‌بخشد، به مهندسان اجازه می‌دهد تا کد جدید را سریع تر و کامل تر درک کنند.
  • اگر کد منبع خود را به عنوان یک محصول حمل می‌کنید، باید مطمئن شوید که آن را نیز به عنوان هر محصول دیگری که ایجاد می‌کنید، بسته‌بندی شده و پاک می‌شود.

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

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

مشخصات پروژه

لازم است که اسناد زیر تولید شوند:

  1. خلاصه پروژه. این چیزی است که پروژه را می‌کِشد. اساساً شرح مختصری از پروژه است و زنجیره رسمی اسناد را تشکیل نمی‌دهد.
  2. مشخص کردن نیازمندی‌ها. این عمل، مشخص می‌کند که پروژه چه کاری را انجام می‌دهد. این کار بخش اساسی زنجیره اسناد است. تمام اسناد دیگر به آن وابسته هستند.
  3. طراحی پروژه. این سند طراحی رسمی پروژه است. این کار ماژول‌ها و اجزاء را مشخص می‌کند، که رابط‌های آن‌ها و نحوه ارتباط آن‌ها چگونه است. مهندس نرم‌افزار، هنگام انجام این کار، به تمام روش‌های مختلف برای طراحی پروژه نگاه می‌کند و بهترین روش‌ها را انتخاب می‌کند. او تمام جنبه‌های فنی، کیفی، مدیریتی، منطقی و تجاری را در نظر می‌گیرد که شامل زمان و هزینه توسعه، نگهداری، پشتیبانی و میزان پیش هزینه‌ها و هزینه‌های جاری است. بخشی از این شغل مربوط به طراحی معماری است، اما بسیار فراتر از آن گسترش می‌یابد.
  4. مشخصات آزمون این کار تمام تست‌هایی که باید اجرا شوند و چه نتایجی باید بررسی شود را تعیین می‌کند. اغلب تست‌ها توسط تست‌های خودکار انجام می‌شود و تست‌های تعیین شده در فایل کدها یا اسکریپت فایل‌ها مشخص می‌شود.
  5. تست کردن نتایج و خروجی‌ها.

تمام مشخصات پروژه به نتایج تست‌ها بستگی دارد که زنجیره اسناد نامیده می‌شود. هر سند دارای یک نسبت ۱:۱ به سند قبلی است؛ و در نهایت مشخصات تست دارای یک رابطه ۱:۱ به مشخصات مورد نیاز است. زنجیره اسناد دو طرفه است - مشخصات کاهش می‌یابد، نتایج و خروجی‌ها به دست می‌آیند.

این روش‌ها، روش‌های رسمی نامیده می‌شوند.

کیفیت

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

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

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

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

کاهش پیچیدگی

پیچیدگی یک فاکتور در مقابل امنیت است.[3]

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

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

هر چه کد پیچیده‌تر باشد، احتمال باگ دار بودن کد بیشتر، پیدا کردن باگ، سخت‌تر و احتمال وجود باگ‌های پنهان بیشتر است.

بازآرایی (Refactoring)

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

روشهای سریع توسعه نرمافزاری برنامه‌ریزی منظم (یا حتی پیوسته) برای بازآرایی، آن را بخش جدایی ناپذیری از فرایند توسعه نرم‌افزار تیم می‌کند.[4]

خودکارسازی

قراردادهای کدنویسی اجازه می‌دهد تا اسکریپت‌های ساده یا برنامه‌هایی داشته باشیم که کار آن‌ها پردازش سورس کد برای اهدافی غیر از کامپایل کردن آن به یک برنامه قابل باشد. معمول این است که طول [خطوط] نرم‌افزار (خطوط سورس کد) را برای پیگیری پیشرفت پروژه یا تعیین خط نشانه ای برای پیاده تخمین‌های آینده پروژه بنا می‌کنند.

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

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

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

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

یک قرارداد در یک زبان ممکن است یک پیشنیاز برای مورد دیگری باشد. قراردادهای زبان بر روی سورس فایل‌های شخصی نیز تأثیر می‌گذارند. هر کامپایلر (یا مفسر) مورد استفاده برای پردازش کد منبع منحصر به فرد است. قواعدی که کامپایلر برای سورس اعمال می‌کند استانداردهای مطلقی را ایجاد می‌کند. به عنوان مثال، کد پایتون بسیار دندانه محور تر از، مثلاً، Perl است، زیرا فاصله سفید (indentation) در واقع برای مفسر (interpreter) معنی دار است. پایتون از آکولاد استفاده نمی‌کند اما perl برای محدود کردن توابع استفاده می‌کند. تغییر در دندانه‌ها به عنوان تعیین‌کننده عمل می‌کند.[7][8] Tcl، که از دستور زیر استفاده می‌کند مانند Perl یا C / C ++ برای تعریف توابع، موارد زیر را اجازه نمی‌دهد، هرچند که برای یک برنامه‌نویس C کاملاً معقول است: 

 set i 0
 while {$i < 10}
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }

دلیل آن، این است که در Tcl، آکولادها تنها برای محدود کردن توابع استفاده نمی‌شود، همان‌طور که در C یا جاوا استفاده نمی‌شود. به‌طور کلی، آکولادها برای دسته‌بندی کلمات به یک آرگومان واحد استفاده می‌شوند.[9][10] در TCL، کلمه while، دو آرگومان می‌گیرد، یک شرط و یک دستور. در مثال بالا، while آرگومان دوم خود یعنی دستورش را از دست داده‌است (زیرا Tcl هم از کاراکترهای خط جدید برای محدود کردن پایان یک دستور استفاده می‌کند).

قراردادهای رایج

قراردادهای برنامه‌نویسی بسیار زیادی وجود دارد؛ برای مثال سبک و سیاق کدهای سبک را ببینید. قراردادهای برنامه‌نویسی مشترک ممکن است زمینه‌های زیر را پوشش دهد:

  • قراردادهای کامنت نویسی
  • قراردادهای سبک دندانه گذاری
  • قراردادهای طول خط
  • قراردادهای نامگذاری
  • برنامه‌های کاربردی
  • اصول برنامه‌نویسی
  • قراردادهای سبک برنامه‌نویسی

استانداردهای کدگذاری عبارتند از CERT C Coding Standard , MISRA C، Integrity C ++.

جستارهای وابسته
  • مقایسه زبان‌های برنامه‌نویسی (نحو)
  • نماد مجارستان
  • سبک برگزاری
  • فهرست ابزارهای تجزیه و تحلیل کد استاتیک
  • سبک برنامه‌نویسی
  • معیارهای نرم‌افزار

منابع
  1. "EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs". EditorConfig.
  2. "Code Conventions for the Java Programming Language: Why Have Code Conventions". Sun Microsystems, Inc. 1999-04-20.
  4. Jeffries, Ron (2001-11-08). "What is Extreme Programming?: Design Improvement". XP Magazine. Archived from the original on 2006-12-15.
  5. Hoff, Todd (2007-01-09). "C++ Coding Standard: Naming Class Files".
  7. van Rossum, Guido (2006-09-19). "Python Tutorial: First Steps Towards Programming". Python Software Foundation. Archived from the original on 28 September 2008. Retrieved 1 February 2019.
  8. Raymond, Eric (2000-05-01). "Why Python?". Linux Journal.
  9. Tcl Developer Xchange. "Summary of Tcl language syntax". ActiveState.
  10. Staplin, George Peter (2006-07-16). "Why can I not start a new line before a brace group". 'the Tcler's Wiki'.

پیوند به بیرون

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

قراردادهای کدنویس برای پروژه‌ها
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.