أعراف البرمجة

مراجعة نظراء للبرامج تتضمن غالبًا قراءة التعليمة برمجية المصدر. يكون هذا النوع من مراجعة النظراء نشاط اكتشاف الخلل بصورة أساسية. وبصورة واضحة لا تتم قراءة عينة التعليمة البرمجية إلا بواسطة المؤلف الأصلي وذلك قبل إرسال التعليمة البرمجية للمراجعة. تكون التعليمة البرمجية التي تتم كتابتها باستخدام إرشادات ثابتة أسهل في فهمها واستعابها بالنسبة للمراجعين الآخرين، مما يؤدي إلى تحسين فعالية عملية اكتشاف الخلل. تعمل البرامج التي بها تعليمات برمجية ثابتة على تسهيل القدرة على الصيانة حتى بالنسبة للمؤلف الأصلي. لا يوجد ضامن على أن الفرد سوف يتذكر الأساس المنطقي الدقيق للسبب وراء كتابة عينة محددة من تعليمة برمجية بطريقة ما بعد مدة طويلة من كتابة التعليمة البرمجية في الأساس. يمكن لقواعد التعليمات المساعدة في هذا الأمر. يعمل الاستخدام المتواصل للمسافة البيضاء على تحسين قابلية القراءة وتقليل الوقت المستغرق في فهم البرامج.

تشير إعادة بناء التعليمات البرمجية إلى نشاط صيانة البرامج حيث يتم تعديل التعليمة برمجية المصدر لتحسين قابلية القراءة أو تحسين هيكلها. تتم غالبًا إعادة بناء التعليمات البرمجية لجعلها متطابقة مع معايير التعليمات البرمجية التي تم إقرارها للفريق بعد الإصدار الأولي. يمكن اعتبار أي تغيير لا يعدل أسلوب البرامج إعادة بناء للتعليمات للبرمجية. تكون أنشطة إعادة بناء التعليمات البرمجية الشائعة أسماء متنوعة متنغيرة أو طرق إعادة تسمية أو طرق متنقلة أو فئات كاملة وطرق كبيرة طارئة (أو وظائف) داخل طرق أصغر. تعمل أساليب التطوير السريع للبرامج على التخطيط لإعادة بناء التعليمات البرمجية بصورة منتظمة (أو حتى مستمرة) بما يجعلها جزءًا متكاملاً من الفريق عملية تطوير البرامج.[2]

على سبيل المثال، في جاوة (جزيرة) ربما يتضمن هذا وجود عبارتين مكتوبتين كالآتي:

a++;
b = a;

ولكن ليس كما يلي:

a++; b = a;

يقترح بعض المبرمجين أن التعليمات البرمجية حيث تكون نتيجة القرار مجرد حساب لقيمة منطقية فإنها تكون إسهابات مفرطة وعرضة لأخطاء. وبالتالي يفضل المبرمجون امتلاك القرار في الحساب نفسه كالآتي:

return (hours < 24) && (minutes < 60) && (seconds < 60);

الاختلاف هنا أسلوبي تمامًا لأن الاستفادة المثلى من المحللين البرمجيين ربما تنتج تعليمة برمجية لكائن لكلا النموذجين. بالرغم من ذلك يوجد بصورة أسلوبية اختلاف بين المبرمجين حول أي من النموذجين هو الأسهل في القراءة والصيانة. تتضمن المناقشات التي تكون في صالح النموذج الأطول ما يلي: من الممكن تحديد نقطة توقف لكل خط على فرع واحد من القرار، كما يمكن إضافة خطوط إضافية للتعليمة البرمجية إلى فرع واحد دون إعادة بناء التعليمات البرمجية لخط العودة، مما يزيد من فرص الأخطاء التي يتم تقديمها كما سيسمح دومًا النموذج الأطول لمصحح الأخطاء بالتخطي إلى سطر لا تزال فيه المتغيرات التي تم استخدامها في النطاق.

في اللغات التي تستخدم رمزًا واحدًا (عادة ما يكون علامة يساوي فردية، (=)) لـ مهمة ورمزًا آخرًا (عادة ما يكون علامة يساوي زوجية، (==) لـ مقارنة (مثل ]]C/C++]]، جاوة (جزيرة)، أكشن سكربت، بي إتش بي، بيرل سياق رقمي وأغلب اللغات في 15 عامًا الماضية)، وحيثما تكون هناك إمكانية لتنفيذ المهام ضمن هياكل تحكم توجد ميزة لتبني نمط المقارنة على اليسار: لوضع ثوابت أو تعبيرات إلى اليسار في أي مقارنة.[9] [10]

فيما يلي كلا النمطين من المقارنات على اليسار وعلى اليمين المطبقة على سطر التعليمة البرمجية بيرل. تقوم هذه المقارنة في كلتا الحالتين بمقارنة القيمة المتغير $a مقابل 42، وفي حالة توافقها، يتم تنفيذ التعليمة البرمجية في المجموعة التالية.

if ( $a == 42 ) { ... } # A right-hand comparison checking if $a equals 42.
if ( 42 == $a ) { ... } # Recast, using the left-hand comparison style.

يحدث الاختلاف عند قيام المطور بكتابة = بدلاً من == دون قصد:

if ( $a = 42 ) { ... } # Inadvertent assignment which is often hard to debug
if ( 42 = $a ) { ... } # Compile time error indicates source of problem

السطر الأول (على اليمين) على خلل دقيق كامن: وبخلاف الأسلوب السابق، يتم تحديد قيمة $a لتكون 42، ثم يتم تشغيل التعليمة البرمجية دومًا في المجموعة التالية. نظرًا لكون هذا صحيحًا من الناحية الإنشائية، فإنه ربما لا تتم ملاحظة الخطأ بواسطة المبرمج وربما يتم شحن البرنامج وهو محتوٍ على خطأ. يحتوي السطر الثاني (على اليسار) على خطأ دلالي حيث لا يمكن تخصيص قيم رقمية له. سوف ينتج عن هذا إنشاء رسالة تشخيصية عند إجراء التحليل البرمجي للتعليمة البرمجية وبالتالي لا يمكن عدم ملاحظة الخطأ بواسطة المبرمج. تحتوي بعض اللغات على وسائل حماية مضمنة ضد المهام غير المتعمدة. على سبيل المثال، لا تدعم جاوة (جزيرة) وC التحويل التلقائي للقيمة المنطقية فقط لهذا السبب. يمكن أيضًا التقليل من حجم المخاطر من خلال استخدام أدوات تحليل التعليمات البرمجية الثابتة والتي يمكنها اكتشاف هذه المشكلة.

يشكل استخدام هياكل التحكم المنطقية مضافًا إليها الهياكل الحلقية نمط برمجة جيدًا أيضًا. فهو يساعد الأشخاص في قراءة التعليمة البرمجية لفهم تسلسل تنفيذ البرنامج بصورة أفضل (في لغات برمجة الأوامر). على سبيل المثال، في التعليمات البرمجية المستعارة:

i = 0
 
while i < 5
print i * 2
i = i + 1
end while
 
print "Ended loop"

يكون جزء التعليمة البرمجية المتكررة متوافقًا مع إرشادات نمط التسمية والمسافات البادئة، لكن ربما يعتبر الاستخدام التالي للتركيب "for" أسهل في القراءة:

for i = 0, i < 5, i=i+1
print i * 2
 
print "Ended loop"

يمكن في العديد من اللغات قصر النمط «لكل عنصر في نطاق» شائع الاستخدام إلى:

for i = 0 to 5
print i * 2
 
print "Ended loop"

أما في لغات البرمجة التي تسمح بالأقواس الكبيرة، فقد أصبح من الشائع لمستندات الأسلوب أن تطلب ذلك حينما يكون اختياريًا، ويتم استخدام الأقواس الكبيرة مع جميع التراكيب تدفق التحكم.

for (i = 0 to 5) {
print i * 2;
}
 
print "Ended loop";

يمنع هذا حدوث أخطاء في البرامج يمكن أن تستنفذ وقتًا في تتبعها، مثل وضع فاصلة منقوطة انتهائية في نهاية التركيب (خطأ هجائي شائع):

 for (i = 0; i < 5; ++i);
    printf("%d\n", i*2);    /* The incorrect indentation hides the fact 
                               that this line is not part of the loop body. */
 
 printf("Ended loop");

...أو عندما تتم إضافة سطر آخر قبل الأول:

 for (i = 0; i < 5; ++i)
    fprintf(logfile, "loop reached %d\n", i);
    printf("%d\n", i*2);    /* The incorrect indentation hides the fact 
                               that this line is not part of the loop body. */
 
 printf("Ended loop");

يتم وضع عناصر في قائمة على أسطر منفصلة، وتعتبر إضافة الفاصلة بين العناصر بعد العنصر النهائي من الممارسات الجيدة بالإضافة إلى وضعها أيضًا بين كل عنصر على الأقل في تلك اللغات التي يكون فعل ذلك مدعومًا بواسطة بناء الجملة (مثل C, جاوة (جزيرة))

const char *array[] = {
    "item1",
    "item2",
    "item3",  /* still has the comma after it */
};

يمنع هذا وجود أخطاء في بناء الجمل أو أخطاء دقيقة في تركيز السلاسل حيث تتم إعادة ترتيب عناصر القائمة أو إضافة المزيد من العناصر إلى النهائدة دون ملاحظة المبرمج وجود فاصلة«مفقودة» على السطر والتي كانت موجودة قبل ذلك في القائمة. بالرغم من ذلك، يمكن أن يتسبب هذا الأسلوب في وجود أخطاء في بناء الجملة (أو دلالات مضللة) في بعض اللغات. حتى في اللغات التي تدعم الفواصل اللاحقة، فربما لا تدعم جميع التراكيب الإعرابية الشبيهة بالقوائم في تلك اللغات ذلك.

• ActionScript: Flex SDK coding conventions and best practices
• Ada: Ada 95 Quality and Style Guide: Guidelines for Professional Programmers
• Ada: Guide for the use of the Ada programming language in high integrity systems^{[وصلة مكسورة]} (ISO/IEC TR 15942:2000)
• Ada: NASA Flight Software Branch — Ada Coding Standard
• Ada: European Space Agency's Ada Coding Standard^{[وصلة مكسورة]} (BSSC(98)3)
• C: Ganssle Group's Firmware Development Standard
• C: Netrino Embedded C Coding Standard
• C: Micrium C Coding Standard
• C++: Quantum Leaps C/C++ Coding Standard
• C++: C++ Programming/Code Style
• C++: GeoSoft's C++ Programming Style Guidelines
• C++: Google's C++ Style Guide
• C#: Design Guidelines for Developing Class Libraries
• C#: Microsoft, Philips Healthcare
• D: The D Style
• Erlang: Erlang Programming Rules and Conventions
• Flex: Code conventions for the Flex SDK
• GML: Game Maker Language
• Java: Ambysoft's Coding Standards for Java
• Java: Code Conventions for the Java Programming Language
• Java: GeoSoft's Java Programming Style Guidelines
• Java: Java Coding Standards على مشروع الدليل المفتوح
• Lisp: Riastradh's Lisp Style Rules
• Mono: Programming style for Mono
• Object Pascal: Object Pascal Style Guide
• Perl: Perl Style Guide
• PHP::PEAR: PHP::PEAR Coding Standards
• Python: Style Guide for Python Code
• Ruby: The Unofficial Ruby Usage Guide
• Ruby: Good API Design^{[وصلة مكسورة]}

• Apache Developers' C Language Style Guide
• Drupal PHP Coding Standards
• GNU Coding Standards
• Linux Kernel Coding Style (or Documentation/CodingStyle in the Linux Kernel source tree)
• ModuLiq Zero Indent Coding Style
• Mozilla Coding Style Guide
• Road Intranet's C++ Guidelines
• The NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)
• "GNAT Coding Style: A Guide for GNAT Developers"، GCC online documentation، Free Software Foundation، مؤرشف من الأصل في 25 مايو 2018، اطلع عليه بتاريخ 19 يناير 2009. (PDF)

• بوابة برمجة الحاسوب
• بوابة علم الحاسوب