ننصح بشدة اتباع هذه القواعد. وليس لهذا الاحترام للقواعد اية علاقة بأفضلياتك الشخصية: فإنه يتيح الحفاظ على تماسك المشروع ووحدته وخاصة الحفاظ على وضوحه كما كان سابقاً. ولا تنسى ان اناس غيرك قد يقومون بقراءة برمجتك ومحاولة فهمها وتعديلها.
من الواضح، على سبيل المثال، ان كتابة دالات SPIP هي ()my_function. في اطار هذا المشروع، يصبح اذاً من غير اللائق بتاتاً اضافة دالات جديدة مكتوبة ()MyFunction - حتى لو ان هذه الكتابة ليست اسوأ من السابقة في المطلق.
كل هذا لا يمنع بالطبع من انتقاد اي قاعدة واقتراح بديل لها قد يكون افضل منها. فلا تتردد عن القيام بذلك على انه يجب ان توجد اسباب وجيهة لذلك.
اخيراً، هناك استثناءات لكل قاعدة، الا انها تتطلب ان يكون هناك اسباب وجيهة للغاية وليس كسل المبرمج فقط، كما يجب ان تكون نادرة الى ابعد حد. خاصة. يجب عدم اغفال ان «المؤقت» غالباً ما يأخد صفة الدائم عندما لا يوجد احد للقيام بتصحيحه خاصة وانه من المنطقي والعادل ان يكون كل مبرمج مسؤولاً عن اتمام برمجته الخاصة وليس برمجة الآخرين.
قواعد التقديم والكتابة
ان القواعد التالية موحدة تطبق في عدد من لغات البرمجة: على الاقل تلك اللغات التي تشبه كتابتها كتابة PHP (اي PHP نفسه وC و++C وJava...).
وهذه القواعد متعارف عليها ومقبولة في البرمجة من جماعة المبرمجين التي تعتبرها مثل قواعد التقديم والكتابة في اللغات الطبيعية لا سيما وان الاثنتين متشابهتان احياناً.
التقديم
– يجب ان تكون الرموز البرمجية متباعدة مع ازاحات متناسبة في اول سطورها (indentation) لإبراز بنيتها والتمييز بين الكتل المنطقية المختلفة (خاصة الدالات). ويجب ان يكون التباعد والازاحة كافيين لجعل البنية مفهومة من النظرة الاولى، ولكن لا يجب الافراط بهما. يجب التعامل معهما بالترتيب نفسه الذي يطبق على فقرات نص باللغة الطبيعية.
– من الافضل ان تتم الازاحة باستخدام مفتاح الحقول (tab). فإن ذلك يسهّل اختيار مدى الازاحة في خيارات معالج النصوص وفي الوقت نفسه لا يفرض هذا الخيار على المطورين الآخرين.
– كل كتلة برمجية موجودة داخل حاصرتين ({}) ستتم ازاحتها حقلاً واحداً. وكذلك الامر للكتل الفرعية دورياً: ازاحة حقل واحد اضافية لكل مرة تبدأ كتلة فرعية في عمق اضافي. وتطبق هذه القاعدة ايضاً على تعريفات الدالات.
– الاوامر البرمجية التي لا تعود الى اي دالة لا تُزاح.
– يجب التقليل قدر المستطاع من استخدام التنقل بين PHP وHTML (اي <?php و?>). ويجب تجنبه لدى عرض مقاطع صغيرة من HTML. يجب التذكير بأن مقطع صغير من PHP غارق في بحر من HTML يختفي كلياً في حال عدم التمحيص القوي.
الكتابة
– عند استخدام الهلالين او القوسين لا يجب ترك مسافة بعد الهلال الفاتح ولا قبل الهلال المغلق.
– عند استخدام عامل ثنائي (+، =، *، AND، ...)، يجب ترك مسافة قبله وبعده. باستثناء الحالات مثل النص الحالي حيث تذكر هذه العوامل ولا تستخدم كعوامل.
– يجب ان يلتصق العامل الاحادي (!، ...) بالوسيط الذي يطبق عليه.
– من المتعارف عليه انه لدى نداء دالة ما، لا يوجد مسافة قبل الهلال الفاتح : «f($x)» وليس «f ($x)». على العكس، وللتوضيح اكثر، يجب ترك مسافة قبل الهلال عندما يتعلق ببنية تحكم مدمجة في اللغة البرمجية: «if (!$x)» وليس «if(!$x)».
– يجب ترك مسافة بعد الفواصل والفواصل المنقوطة وليس قبلها.
قواعد البرمجة
التفكير
قبل برمجة اي وظيفة يجب التفكير ملياً...
– في الطريقة والخوارزمي المستخدم لتنفيذها: برمجة خفيفة واداء ومتانة (عدم التردد في تنفيذ حسابات مباشرة للتأكد من البرمجة)
– في التوافق مع المشروع: هل يمكن نقلها، هل هي آمنة، هل هي مرنة
– في التأثير على الوظائف الاخرى: التعديلات والاضافات المطلوب ادخالها على الوظائف الموجودة
– في الموقع «الطبيعي» لهذه الوظيفة ضمن المشروع: في ما يتعلق بواجهة الاستخدام والملفات الضرورية الخ.
عدم تجاهل التحليل وتوحيد الاوامر البرمجية (بواسطة دالات لا سيما في الملفات التي يجب ادراجها). في المقابل تجنب الملفات المدرجة التي تحتوي على رموز برمجية خارج الدالات (الا اذا كان «طبيعياً» ومقصوداً).
التسمية
– المتغيرات والدالات:
مهما كان المشروع، يجب ان يبقى اعطاء الاسماء متناسقاً لتبقى الاوامر البرمجية واضحة لدى القراءة. لذلك، في SPIP، يجب ان تكون اسماء المتغيرات والدالات بالحروف الصغيرة (lower case)، والاسماء المركبة على شكل متغير_مركب.
بشكل عام، يجب ان لا تكون الاسماء قصيرة جداً ولا طويلة جداً وان تدل على معناها بوضوح. هذه القاعدة مهمة جداً خاصة للمتغيرات الشاملة (global) التي يتم استخدامها في اكثر من ملف واحد ودالة واحدة. اما في ما يتعلق بالمتغيرات المحلية (local) المستخدمة في دالة واحدة، فالقاعدة اكثر مرونة. فيمكن مثلاً استخدام اسماء مكونة من حرف واحد للحصول على تركيبات متراصة. لاحظ انه في كل لغات البرمجة، تقليدياً، هناك عدد من الحروف المرتبطة بأنواع من الاستخدامات (مثلاً: $i و$j لعدادات الحلقات و$n للتعداد و$t للدلالة على لحظة او فترة بالثواني...). فاتباع هذه التقاليد يجنب القارئ الشعور بالغربة.
– الملفات:
لأسباب تاريخية، تمت تسمية الملفات التي يجب ادراجها في الموقع العمومي inc-file.php. اما في المجال الخاص، فتكون ecrire/inc_file.php (لاحظ الخط التحتي بدلاً من الخط العادي). اما ملفات الموقع العمومي التي يتم نداؤها بإعادة توجيه HTTP من المجال الخاص، فإسمها spip_file.php. واما سائر الملفات الاخرى فأسماؤها لا تبدأ لا بـ«inc» ولا بـ«spip».
الاختبار
عندما يتم اضافة تعديل مهم، يستحسن اختباره من قبل مطوره دون الانتظار حتى يختبره شخص آخر. ويعني ذلك، في اطار SPIP، التأكد من ان البرنامج يعمل بشكل صحيح لدى عدد من مضيفي المواقع المختلفين وفي عدد من الاعدادات المختلفة (مثل اصدارات مختلفة من PHP وMySQL وفي وضع اذونات محدودة للوصول الى الادلة وغير ذلك)، والتأكد كذلك من ان عدد من الحالات الشائعة (في حال واجهة تخطيطية مثلاً) قد تم اخذه في الحسبان.
توزيع تعديلاتك
عندما تصير راضياً عن التعديلات التي طورتها، يأتي وقت الاعلان عنها بين المطورين الآخرين والتشاور في تأهيلها للدخول في توزيع SPIP الرسمي ... الى اللقاء في قائمة مطوري SPIP البريدية: spip-dev.
الى اللقاء!