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

من أرابيكا، الموسوعة الحرة
اذهب إلى التنقل اذهب إلى البحث

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

صيانة البرامج

يعد تقليل تكلفة صيانة البرامج السبب الأكثر ذكرًا لقواعد التعليمات البرمجية التالية. في مقدمتها لقواعد التعليمات البرمجية الخاصة بلغة برمجة Java، توضح Sun Microsystems الأسس المنطقية التالية:[1]

تكون قواعد التعليمات البرمجية مهمة للمبرمجين وذلك لعدة أسباب:

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

الجودة

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

إعادة بناء التعليمات البرمجية

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

التشغيل التلقائي للمهام

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

معاملات اللغة

يجب على جميع العاملين في مجال البرامج وضع أيديهم على المشكلات المتعلقة بتنظيم الإرشادات الأكثر تفصيلاً وإدارتها، حيث ستتم معالجة كل منها في آخر الأمر بهدف تنفيذ المهمة التي كُتبت من أجلها. يتم تقسيم التعليمة برمجية المصدر (الإرشادات) إلى ملفات منفصلة وبين عدة دلائل غالبًا وذلك بالنسبة لجميع مشروعات البرامج، باستثناء الأصغر منها. كان طبيعيًا بالنسبة للمبرمجين تجميع الوظائف ذات الصلة الشديدة (الأساليب) في الملف نفسه وتجميع الملفات ذات الصلة داخل دلائل. ونظرًا لكون تطور البرامج قد نشأ من برمجة إجرائية مجردة (مثلما هو موجود في فورتران) تجاه تراكيب توجهها الأهداف بصورة أكثر (مثلما هو موجود في سي++)، فقد أصبحت الممارسة هي كتابة تعليمة برمجية لفئة واحدة (عمومية) في ملف فردي (قاعدة «فئة واحدة لكل ملف»).[3][4] ارتقت جاوة (جزيرة) إلى خطوة واحدة أعلى - حيث قام المحول البرمجي لـ Java بإعادة خطأ في حالة وجود أكثر من فئة عمومية واحدة لكل ملف. ربما يكون وجود قاعدة في لغة واحدة مطلبًا في أخرى. تقوم قواعد اللغة بالتأثير أيضًا على ملفات المصدر الفردية. يكون كل محول برمجي (أو مترجم) تتم الاستعانة به لمعالجة تعليمة برمجية المصدر فريدًا. تقوم القواعد التي يطبقها المحول البرمجي على المصدر بإنشاء معايير ضمنية. على سبيل المثال، تكون المسافة البادئة موجودة بشكل أكثر مع التعليمة البرمجية Python مقارنة بالتعليمة البرمجية Perl مثلاً نظرًا لكون المسافة البيضاء (المسافة البادئة) مهمة في حقيقة الأمر للمترجم. لا تستعن Python ببناء الجمل في أقواس كبيرة مثلما هو الحال في Perl لتحديد الوظائف. تعمل التغييرات في المسافة البادئة كمحددات.[5][6] لا تسمح Tcl التي تستعن ببناء الجمل في أقواس كبيرة مشابهة لـ Perl أو C/C++ لتحديد الوظائف بالأمور التالية والتي تبدو منطقية بصورة واضحة لمبرمج C: 

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

يكون السبب في عدم استخدام الأقواس الكبيرة بشكل مجعد في Tcl وذلك لتحديد الوظائف فقط كما هو الحال في C أو Java. يتم استخدام الأقواس الكبيرة بشكل مجعد لتجميع كلمات معًا داخل وسيطة فردية وذلك بشكل أكثر عمومًا.[7][8] في Tcl تأخذ الكلمة بينما وسيطتين وشرط وإجراء. في المثال الموضح أعلاه، تفقد الكلمة بينما وسيطتها الثانية والإجراء الخاص بها (نظرًا لقيام Tcl باستخدام خاصية خط جديد أيضًا لتحديد نهاية الأمر).

القواعد العامة

كما هو موضح أعلاه، ربما تغطي قواعد التعليمات البرمجية العامة المجالات التالية:

أمثلة

يجب أن تظهر عبارة واحدة فقط لكل سطر

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

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 */
};

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

انظر أيضا

المراجع

  1. ^ "Code Conventions for the Java Programming Language : Why Have Code Conventions". Sun Microsystems, Inc. 20 أبريل 1999. مؤرشف من الأصل في 2012-06-26.
  2. ^ Jeffries، Ron (8 نوفمبر 2001). "What is Extreme Programming? : Design Improvement". XP Magazine. مؤرشف من الأصل في 2009-07-12.
  3. ^ Hoff، Todd (9 يناير 2007). "C++ Coding Standard : Naming Class Files". مؤرشف من الأصل في 2018-10-19.
  4. ^ FIFE coding standards نسخة محفوظة 17 فبراير 2012 على موقع واي باك مشين.
  5. ^ van Rossum، Guido (19 سبتمبر 2006). "Python Tutorial : First Steps Towards Programming". Python Software Foundation. مؤرشف من الأصل في 2008-09-28. {{استشهاد ويب}}: الوسيط author-name-list parameters تكرر أكثر من مرة (مساعدة)
  6. ^ Raymond، Eric (1 مايو 2000). "Why Python?". Linux Journal. مؤرشف من الأصل في 2019-05-10.
  7. ^ Tcl Developer Xchange. "Summary of Tcl language syntax". ActiveState. مؤرشف من الأصل في 2018-10-11.
  8. ^ Staplin، George Peter (16 يوليو 2006). "Why can I not start a new line before a brace group". 'the Tcler's Wiki'. مؤرشف من الأصل في 2018-04-02.
  9. ^ Sklar، David (2003). PHP Cookbook. O'Reilly. {{استشهاد بكتاب}}: الوسيط author-name-list parameters تكرر أكثر من مرة (مساعدة), recipe 5.1 "Avoiding == Versus = Confusion", p118
  10. ^ "C Programming FAQs: Frequently Asked Questions". Addison-Wesley, 1995. Nov. 2010. مؤرشف من الأصل في 26 فبراير 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (مساعدة)

وصلات خارجية

قواعد الترميز للغات

قواعد الترميز للمشروعات

مجلوبة من «https://3rabica.org/index.php?title=أعراف_البرمجة&oldid=1515571»