أعراف كتابة الشيفرة البرمجية

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

دعنا نتعرف على هذه الأعراف!

يُقصد بمصطلح PEP: "مقترحات بايثون التعزيزية" (Python Enhancement Proposal). هذه المُقترحات مُفهرسة ومُستضافة على موقع بايثون الرسمي، وتُقسم إلى عدد من التصنيفات، منها: meta-PEPs، وهي مقترحات نظريّة أكثر من تقنيّة. أما على الجانب الآخر، فتصف المقترحات التقنيّة عادةً أشياء مثل تحسين الأجزاء الداخلية للغة.

يوجد بضعة مقترحات مثل PEP 8 و PEP 257 تهدف إلى إرشادك إلى الطريقة التي نكتب بها التعليمات البرمجية. يحتوي المُقترح PEP 8 على دليل تنسيق التعليمات البرمجية. أمّا المُقترح PEP 257 فيحتوي على دليل حول السلاسل التوثيقية (Docstrings)، وهي الطريقة المقبولة عموماً لتوثيق التعليمات البرمجية.

المُقترح PEP 8: دليل تنسيق الشيفرات البرمجية في لغة بايثون

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

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

المُقترح PEP 257: السلاسل التوثيقيّة

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

def launch_rocket():
   """Main launch sequence director.

   Locks seatbelts, initiates radio and fires engines.
   """
   # [...]

تُستخدم هذه الأنواع من السلاسل التوثيقية بواسطة برمجيات مثل Sphinx لتوليد ملفات توثيقية بصيغة HTML و PDF وغيرها من الصيغ الأخرى. كما تجعل هذه السلاسل التعليمات البرمجية أكثر سهولة من ناحية الفهم.

ملاحظة

• المُقترح PEP 8
• المُقترح PEP 257
• برمجية Sphinx، مُولِد توثيقات مكتوب بواسطة نفس الأشخاص الذين اخترعوا إطار فلاسك

الاستيرادات النسبية

يجعل الاستيراد النسبي الأمور أسهل عند تطوير التطبيقات التي تستخدم إطار فلاسك. هذه التقنية بسيطة وسهلة لأبعد الحدود، وإليك هذا المثال للتوضَّح أكثر: دعنا نقول أنك تريد استيراد الوحدة User من الملف myapp/models.py. قد تظن أنك يجب أن تكتب اسم الحزمة بهذا الشكل myapp.models، ولكن باستخدام الاستيرادات النسبية يمكنك تحديد موقع الوحدة الهدف تبعاً لمكان تواجدها (مصدرها). للقيام بهذا نستخدم النقطة، بحيث أول نقطة تحدد الدليل (directory) الحالي وكل نقطة لاحقة تمثل الدليل الأب التالي (الدليل الحاوي للدليل الحالي). المثال أدناه يوضح الفرق بين طريقة كتابة الاستيراد المطلق والنسبي.

# myapp/views.py

# User طريقة الاستيراد المطلق لجلب الوحدة
from myapp.models import User

# طريقة الاستيراد النسبي، وهي تفعل نفس الشيء
from .models import User

إحدى محاسن هذه الطريقة أنَّ الحزمة تصبح أكثر معيارية. فيمكنك الآن إعادة تسمية الحزمة وإعادة استخدام وحداتها من مشروع آخر دون الحاجة لتحديث تعليمات الاستيراد.

وجدتُ تغريدةً، خلال بحثي، توضِّح فائدة الاستيرادات النسبية، تقول:

استغرق الأمر دقيقة واحدة لإعادة تسمية الحزمة بأكملها، يا لروعة الاستيراد النسبي!

— David Beazley, @dabeaz

ملاحظة
يمكنك قراءة المزيد حول الصيغة الكتابية للاستيرادات النسبية في القسم المخصص لها في المُقترح PEP 328

الخلاصة

• حاول اتباع أعراف تنسيق التعليمات البرمجية الموضوعة في المُقترح PEP 8.
• حاول توثيق تطبيقك بالسلاسل التوثيقية المشروحة في المُقترح PEP 257.
• استخدم الاستيراد النسبي لاستيراد الوحدات الداخليّة في تطبيقك.