اصطلاحات البرمجة

تُعدّ اصطلاحات البرمجة مجموعة من الإرشادات الخاصة بلغة برمجة مُحددة ، تُوصي بأسلوب البرمجة والممارسات والأساليب المُتبعة في كل جانب من جوانب البرنامج المكتوب بتلك اللغة. تشمل هذه الاصطلاحات عادةً تنظيم الملفات، والمسافات البادئة ، والتعليقات ، والتصريحات ، والعبارات ، والمسافات البيضاء ، واصطلاحات التسمية ، وممارسات البرمجة ، ومبادئ البرمجة ، وقواعد البرمجة العامة، وأفضل الممارسات المعمارية، وغيرها. تُعتبر هذه الاصطلاحات بمثابة إرشادات لجودة بنية البرمجيات . يُنصح بشدة مُبرمجي البرمجيات باتباع هذه الإرشادات لتحسين قابلية قراءة شفرة المصدر وتسهيل صيانة البرمجيات . تنطبق اصطلاحات البرمجة فقط على القائمين على صيانة البرمجيات ومراجعيها من قِبل النظراء . قد تكون هذه الاصطلاحات مُوثقة في مجموعة من القواعد التي يتبعها فريق أو شركة بأكملها، [ 1 ] أو قد تكون غير رسمية مثل ممارسات البرمجة المُعتادة للفرد. لا تُفرض اصطلاحات البرمجة بواسطة المُترجمات .
صيانة البرامج
يُعدّ خفض تكلفة صيانة البرمجيات السبب الأكثر شيوعًا لاتباع معايير البرمجة. في القسم التمهيدي حول معايير البرمجة للغة جافا، تُقدّم شركة صن مايكروسيستمز التبرير التالي: [ 2 ]
تُعدّ قواعد البرمجة مهمة للمبرمجين لعدة أسباب:
- تتراوح نسبة تكلفة صيانة البرامج طوال فترة استخدامها بين 40% و80%. [ 3 ]
- نادراً ما يتم صيانة أي برنامج طوال فترة استخدامه من قبل مؤلفه الأصلي.
- تعمل اصطلاحات كتابة التعليمات البرمجية على تحسين قابلية قراءة البرنامج، مما يسمح للمهندسين بفهم التعليمات البرمجية الجديدة بسرعة أكبر وبشكل أكثر شمولاً.
- إذا كنت تقوم بشحن شفرة المصدر الخاصة بك كمنتج، فأنت بحاجة إلى التأكد من أنها معبأة ونظيفة بنفس جودة أي منتج آخر تقوم بإنشائه.
جودة
غالبًا ما تتضمن مراجعة البرمجيات من قبل النظراء قراءة شفرة المصدر. يُعد هذا النوع من المراجعة نشاطًا أساسيًا لاكتشاف العيوب . وبحسب التعريف، فإن المؤلف الأصلي للشفرة هو الوحيد الذي يقرأ ملف المصدر قبل تقديم الشفرة للمراجعة. الشفرة المكتوبة وفقًا لإرشادات متسقة يسهل على المراجعين الآخرين فهمها واستيعابها، مما يُحسّن من فعالية عملية اكتشاف العيوب.
حتى بالنسبة للمبرمج الأصلي، فإن كتابة البرامج بأسلوب متسق تُسهّل صيانتها. فليس هناك ما يضمن أن يتذكر الشخص السبب الدقيق لكتابة جزء معين من الكود بطريقة محددة بعد فترة طويلة من كتابته. وهنا يأتي دور قواعد البرمجة. فالاستخدام المتسق للمسافات البيضاء يُحسّن من سهولة قراءة الكود ويُقلل من الوقت اللازم لفهم البرنامج.
معايير الترميز
عندما تُصمَّم قواعد البرمجة خصيصًا لإنتاج كود عالي الجودة، ثم تُعتمد رسميًا، فإنها تُصبح معايير برمجية. أما الأساليب المحددة، بغض النظر عن مدى شيوع استخدامها، فلا تُنتج بالضرورة كودًا عالي الجودة.
تقليل التعقيد
يُعدّ التعقيد عاملاً يُعيق الأمن. [ 4 ]
تتضمن إدارة التعقيد المبدأ الأساسي التالي: تقليل حجم الشيفرة البرمجية المكتوبة أثناء تطوير المشروع. هذا يمنع العمل غير الضروري، وبالتالي يقلل التكاليف غير الضرورية، سواءً في البداية أو في المراحل اللاحقة. ببساطة، كلما قلّت الشيفرة البرمجية، قلّ الجهد المبذول ليس فقط في إنشاء التطبيق، بل في صيانته أيضاً.
تُدار التعقيدات في مرحلتي التصميم (كيفية بناء المشروع) والتطوير (من خلال تبسيط الشيفرة البرمجية). فإذا كانت الشيفرة بسيطة وسهلة الفهم، سيقل التعقيد إلى أدنى حد. وغالبًا ما يكون ذلك من خلال جعل الشيفرة "مادية" قدر الإمكان، أي كتابة الشيفرة بطريقة مباشرة وغير مجردة. ينتج عن ذلك شيفرة مثالية سهلة القراءة والفهم. كما يمكن تجنب التعقيد ببساطة عن طريق عدم استخدام أدوات معقدة للمهام البسيطة.
كلما كان الكود أكثر تعقيدًا، زادت احتمالية وجود أخطاء فيه، وزادت صعوبة العثور على هذه الأخطاء، وزادت احتمالية وجود أخطاء خفية.
إعادة هيكلة
إعادة هيكلة البرمجيات هي عملية صيانة يتم فيها تعديل شفرة المصدر لتحسين سهولة قراءتها أو تحسين بنيتها. غالبًا ما تُعاد هيكلة البرمجيات لجعلها متوافقة مع معايير البرمجة المعتمدة من قبل الفريق بعد إصدارها الأولي. أي تغيير لا يؤثر على سلوك البرنامج يُعتبر إعادة هيكلة. تشمل أنشطة إعادة الهيكلة الشائعة تغيير أسماء المتغيرات، وإعادة تسمية الدوال، ونقل الدوال أو الفئات بأكملها، وتقسيم الدوال الكبيرة إلى دوال أصغر.
تُخطط منهجيات تطوير البرمجيات الرشيقة لإعادة هيكلة منتظمة (أو حتى مستمرة) مما يجعلها جزءًا لا يتجزأ من عملية تطوير البرمجيات الجماعية . [ 5 ]
أتمتة المهام
تسمح قواعد البرمجة للمبرمجين بكتابة برامج نصية بسيطة أو برامج تُعنى بمعالجة شفرة المصدر لأغراض أخرى غير تحويلها إلى ملف تنفيذي. ومن الممارسات الشائعة حساب حجم البرنامج ( عدد أسطر شفرة المصدر ) لتتبع تقدم المشروع الحالي أو لتحديد أساس لتقديرات المشاريع المستقبلية .
تساهم معايير البرمجة المتسقة بدورها في جعل القياسات أكثر اتساقًا. غالبًا ما تُستخدم وسوم خاصة ضمن تعليقات شفرة المصدر لمعالجة التوثيق، ومن أبرز الأمثلة على ذلك Javadoc و Doxygen . تُحدد هذه الأدوات استخدام مجموعة من الوسوم، ولكن استخدامها داخل المشروع يخضع للاتفاقية.
تُسهّل قواعد البرمجة كتابة برامج جديدة تُعنى بمعالجة البرامج الموجودة. وقد ازداد استخدام تحليل الشفرة الثابتة بشكل مطرد منذ خمسينيات القرن الماضي. ويعود جزء من نمو هذه الفئة من أدوات التطوير إلى نضج وتطور الممارسين أنفسهم (والتركيز الحديث على السلامة والأمان )، بالإضافة إلى طبيعة لغات البرمجة نفسها .
العوامل اللغوية
يواجه جميع ممارسي البرمجيات مشكلة تنظيم وإدارة عدد كبير من التعليمات، والتي قد تكون معقدة أحيانًا. في معظم مشاريع البرمجيات، باستثناء المشاريع الصغيرة جدًا، يُقسّم كود المصدر (التعليمات) إلى ملفات منفصلة ، وغالبًا ما يكون موزعًا على عدة مجلدات . كان من الطبيعي أن يجمع المبرمجون الدوال (السلوكيات) المترابطة في ملف واحد، وأن يجمعوا الملفات ذات الصلة في مجلدات. مع تحوّل تطوير البرمجيات من البرمجة الإجرائية البحتة (كما في لغة فورتران ) إلى بنى أكثر توجهاً نحو الكائنات (كما في لغة سي++ )، أصبح من الممارسات الشائعة كتابة كود فئة واحدة (عامة) في ملف واحد (اتفاقية "فئة واحدة لكل ملف"). [ 6 ] [ 7 ] وقد خطت لغة جافا خطوة أبعد من ذلك، حيث يُرجع مُصرّف جافا خطأً إذا وجد أكثر من فئة عامة واحدة في الملف الواحد.
قد يكون أحد الاصطلاحات في لغة برمجة ما شرطًا أساسيًا في لغة أخرى. كما تؤثر اصطلاحات اللغات على ملفات المصدر الفردية. كل مُصرّف (أو مُفسّر) يُستخدم لمعالجة شفرة المصدر فريد من نوعه. تُنشئ القواعد التي يُطبقها المُصرّف على المصدر معايير ضمنية. على سبيل المثال، تكون مسافة بادئة شفرة بايثون أكثر اتساقًا من شفرة بيرل، لأن المسافات البيضاء (المسافة البادئة) ذات أهمية فعلية للمُفسّر. لا تستخدم بايثون صيغة الأقواس التي تستخدمها بيرل لفصل الدوال. التغييرات في المسافة البادئة هي التي تُحدد الدوال. [ 8 ] [ 9 ] أما لغة Tcl ، التي تستخدم صيغة أقواس مشابهة لبيرل أو C/C++ لفصل الدوال، فلا تسمح بما يلي، وهو أمر يبدو منطقيًا لمبرمج لغة C:
اجعل i = 0 بينما { $i < 10 } { اطبع "$i تربيع = [expr $i*$i]" زد i }السبب هو أنه في لغة Tcl، لا تُستخدم الأقواس المعقوفة فقط لتحديد الدوال كما هو الحال في لغتي C أو Java. بل تُستخدم بشكل عام لتجميع الكلمات معًا في وسيط واحد. [ 10 ] [ 11 ] في Tcl، تأخذ الدالة while وسيطين: شرطًا وفعلًا . في المثال أعلاه، تفتقر while إلى وسيطها الثاني، وهو الفعل (لأن Tcl تستخدم أيضًا حرف السطر الجديد لتحديد نهاية الأمر).
الاتفاقيات الشائعة
توجد العديد من قواعد البرمجة؛ راجع قسم "أسلوب البرمجة" للاطلاع على أمثلة ومناقشات عديدة. قد تغطي قواعد البرمجة الشائعة المجالات التالية:
- قواعد التعليق
- اصطلاحات نمط المسافة البادئة
- اصطلاحات طول الخط
- اصطلاحات التسمية
- ممارسات البرمجة
- مبادئ البرمجة
- قواعد أسلوب البرمجة
تشمل معايير البرمجة معيار CERT C للبرمجة ، و MISRA C ، و High Integrity C++ .
انظر أيضاً
مراجع
- ↑ "يساعد EditorConfig المطورين على تحديد أنماط كتابة برمجية متسقة والحفاظ عليها بين مختلف المحررات وبيئات التطوير المتكاملة" . EditorConfig .
- ↑ "اتفاقيات كتابة التعليمات البرمجية للغة برمجة جافا : لماذا نحتاج إلى اتفاقيات كتابة التعليمات البرمجية؟" . شركة صن مايكروسيستمز، 20 أبريل 1999.
- ↑ روبرت ل. جلاس: حقائق ومغالطات هندسة البرمجيات؛ أديسون ويسلي، 2003.
- ↑ توم جيليس. "التعقيد عدو الأمن" .
- ↑ جيفريز، رون (2001-11-08). "ما هي البرمجة المتطرفة؟: تحسين التصميم" . مجلة إكس بي. مؤرشف من الأصل في 2006-12-15.
- ↑ هوف، تود (2007-01-09). "معيار ترميز C++ : تسمية ملفات الفئات" .
- ↑ معايير ترميز FIFE
- ↑ فان روسوم، غيدو (19 سبتمبر 2006). فريد ل. دريك الابن (محرر). "دليل بايثون : الخطوات الأولى نحو البرمجة" . مؤسسة برمجيات بايثون. مؤرشف من الأصل في 28 سبتمبر 2008. تم الاطلاع عليه في 17 أغسطس 2014 .
- ↑ ريموند، إريك (2000-05-01). "لماذا بايثون؟" . مجلة لينكس.
- ↑ تبادل مطوري لغة Tcl. "ملخص لبنية لغة Tcl" . ActiveState.
- ↑ ستابلين، جورج بيتر (16-07-2006). "لماذا لا يمكنني بدء سطر جديد قبل مجموعة الأقواس؟" . "موسوعة تكلرز".
- شفرة المصدر
