أنشأ راندال مونرو Randall Munroe في مدونة الكاريكاتير XKCD مخططًا تقنيًا لصاروخ "زحل الخامس" تحت عنوان "Up Goer Five" مُستخدمًا فقط الكلمات الإنجليزية الألف الأشهر، إذ بسّط المصطلحات التقنية إلى جمل يستطيع أي طفل فهمها، إلا أن هذا الأمر يسلط الضوء أيضًا على تفسير عدم إمكانية شرح أي شيء باستخدام مصطلحات بسيطة؛ فالشرح القائل "شيء يساعد الناس على الهرب بسرعة كبيرة في حال وجود مشكلة واشتعال كل شيء ما يجعلهم يقررون عدم الذهاب إلى الفضاء" أسهل فهمًا للمتلقي العادي من عبارة "بدء نظام الهروب Launch Escape System". الشرح الأول مبالغ بإطالته ليستخدمه مهندسو الإدارة الوطنية للملاحة الجوية والفضاء NASA في عملهم اليومي، بل أنهم حتى قد يفضلون استخدام الاختصار LES.

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

تعاريف

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

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

لغة بايثون ومفسر بايثون

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

يمكن أن نقول "تُشغّل بايثون برنامجًا" أو "ستعرض بايثون استثناءً"، والمقصود هنا هو مفسر بايثون -وهو البرنامج الفعلي المسؤول عن قراءة النصوص ضمن الملفات ذات اللاحقة "py." مُنفذًا التعليمات الواردة فيها؛ فعندما نقول "مفسر بايثون"، نقصد غالبًا "CPython"، وهو المفسر المُعتمد من قبل مؤسسة بايثون للبرمجيات Python Software Foundation. إذًا، CPython هو تنفيذ للغة بايثون، بمعنى أنه برمجية أُنشئت لتحقق مواصفات محددة، ولكن يوجد برمجيات غيرها؛ ففي حين أن المفسر CPython مكتوب بلغة البرمجة سي C، المفسر Jython مكتوبٌ بلغة جافا Java بغية تشغيل نصوص بايثون البرمجية القابلة للتشغيل المتبادل مع برامج جافا؛ أما PyPy فهو مترجم ديناميكي just-in-time compiler لبايثون والذي يترجم البرامج لدى تنفيذها، فهو مكتوبٌ بلغة بايثون.

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

كنس المهملات Garbage Collection

كان على المبرمج سابقًا في لغات البرمجة القديمة توجيه البرنامج لتخصيص أو إلغاء تخصيص أو تحرير الذاكرة لبنى المعطيات حسب الحاجة، وقد كانت عملية تخصيص الذاكرة اليدوية هذه مصدرًا للعديد من الأخطاء، مثل تسريبات الذاكرة memory leaks (التي تحدث عند نسيان المبرمج لتحرير الذاكرة) أو أخطاء التحرير المزدوج للذاكرة double-free bugs (إذ يحرر المبرمج نفس الجزء من الذاكرة مرتين، متسببًا في تلف البيانات).

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

>>> def someFunction():
...     print('someFunction() called.')
...     spam = ['cat', 'dog', 'moose']
...
>>> someFunction()
someFunction() called.

تخصص بايثون لدى استدعاء الدالة ()someFunction الذاكرة للقائمة ['cat', 'dog', 'moose']. وبالتالي ما من حاجة لمعرفة المبرمج عدد البايتات من الذاكرة المتوجب طلبها لأن بايثون تدير هذا الأمر نلقائيًا، إذ سيحرر مُجمّع المهملات المتغيرات المحلية بمجرد إعادة الدالة المُستدعاة، ما يجعل الذاكرة متاحةً لبيانات جديدة. إذًا، يجعل مفهوم تجميع المهملات من البرمجة أمرًا أسهل وأقل عرضة للأخطاء.

القيم المجردة Literals

القيمة المجردة هي نص ضمن الشيفرة المصدرية ذات قيمة ثابتة كما هي مكتوبة. ففي المثال التالي 42 هو قيمة صحيحة مجردة و 'Zophie' هي سلسلة نصية مجردة.:

>>> age = 42 + len('Zophie')

يمكن فهم القيم المجردة مثل قيم تظهر كما هي بحرفيتها مثل نص ضمن الشيفرة المصدرية، ولا يمكن إلا لأنواع البيانات المُعرّفة أصلًا في بايثون امتلاك قيم مجردة في الشيفرة المصدرية، وبالتالي ليس المتغير age قيمة مجردة. يبيّن الجدول 1 التالي بعض الأمثلة عن القيم المجردة في بايثون.

قد يجادل بعض المعترضين في أن بعضًا من القيم لا يمثّل قيمًا مجردة استنادًا إلى التوثيق الرسمي للغة بايثون، فمن الناحية التقنية، 5- ليست قيمة مجردة في بايثون لأن اللغة تعرّف رمز السالب (-) مثل عامل على القيمة المجردة 5، كما تُعد القيم True و False و None كلمات مفتاحية في بايثون وليست قيمًا مجردة، في حين أن [] و{} تسمى مُخرجات أو ذرات atoms اعتمادًا على جزء التوثيق الرسمي الذي تبحث ضمنه. بغض النظر عن ذلك، القيمة المجردة هي مصطلح شائع يستخدمه محترفو البرمجيات للدلالة على كل الأمثلة السابقة.

الكلمات المفتاحية Keywords

تمتلك كل لغة برمجة الكلمات المفتاحية الخاصة بها؛ وكلمات بايثون المفتاحية هي مجموعة من الأسماء المحجوزة للاستخدام مثل جزء من بناء اللغة والتي لا يمكن استخدامها أسماءً للمتغيرات (أي المعرّفات). على سبيل المثال، لا يمكنك تسمية أحد المتغيرات بالاسم while لأنها كلمة محجوزة للاستخدام في حلقات while التكرارية، وفيما يلي الكلمات المفتاحية المحجوزة في بايثون وفقًا للإصدار 3.9 منها.

نلاحظ أن كلمات بايثون المفتاحية هي دومًا باللغة الإنجليزية وغير متاحة بأي لغات أخرى. فعلى سبيل المثال، في الدالة التالية المعرفات مكتوبة باللغة الاسبانية، في حين بقيت الكلمتين def و return المفتاحيتين في بايثون بالإنجليزية:

def agregarDosNúmeros(primerNúmero, segundoNúmero):
    return primerNúmero + segundoNúmero

تهيمن اللغة الإنجليزية لسوء الحظ على مجال البرمجة بالنسبة للتعداد البالغ 6.5 مليار من غير الناطقين بها.

الكائنات Objects والقيم Values والنسخ Instances والهويات Identities

يمثّل الكائن جزءًا من البيانات سواء كانت عددًا أو بعضًا من النصوص أو هيكل بيانات أكثر تعقيدًا، مثل القائمة، أو القاموس. ويمكن تخزين الكائنات ضمن متغيرات وتمريرها مثل وسطاء عند استدعاء الدوال واستخدامها مثل قيمة معادة عن استدعاء الدوال.

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

يُنشَأ الكائن بهوية، وهي رقم صحيح فريد من الممكن الإطلاع عليه باستدعاء الدالة ()id. على سبيل المثال، لنكتب ما يلي في الصدفة التفاعلية:

>>> spam = ['cat', 'dog', 'moose']
>>> id(spam)
33805656

يُخزّن المتغير spam كائنًا من نوع البيانات "قائمة"، قيمته تساوي ['cat', 'dog', 'moose'] أما هويته فهي 33805656، رغم كون العدد الصحيح ID هذا يتغير في كل مرة يُنفّذ فيها البرنامج، وبالتالي ستكون القيمة على حاسوبك مختلفة عن هذه المعروضة هنا، ولكن بمجرد إنشاء الكائن، لن تتغير قيمة هويته طالما أن البرنامج قيد التشغيل، ورغم أن كلًا من هوية ونوع بيانات الكائن لا يتغيران أثناء تشغيل البرنامج، إلا أن قيمته قد تتغير، كما في المثال التالي:

>>> spam.append('snake')
>>> spam
['cat', 'dog', 'moose', 'snake']
>>> id(spam)
33805656

وبذلك أصبحت القائمة تتضمّن أيضًا العنصر 'snake'، ولكن وكما هو مبين من نتيجة استدعاء الدالة (id(spam أن هويتها لم تتغير وبقيت نفسها، ولكن ماذا لو كتبنا الشيفرات التالية:

>>> spam = [1, 2, 3]
>>> id(spam)
33838544

استُبدلت القيمة في المتغير spam بكائن قائمة جديد وبهوية جديدة قيمتها 33838544 بدلًا عن 33805656، إذ يختلف المعرف spam عن مفهوم الهوية من حيث أن عدّة معرفات قد تتبع لكائن واحد، كما في المثال التالي الذي أسندنا فيه متغيرين لنفس القاموس:

>>> spam = {'name': 'Zophie'}
>>> id(spam)
33861824
>>> eggs = spam
>>> id(eggs)
33861824

ومنه نجد أن هوية كل من المعرفين spam و eggs نفسها وتساوي 33861824، لأنهما يتبعان لنفس كائن القاموس. الآن وبتغيير قيمة spam في الصدفة التفاعلية:

>>> spam = {'name': 'Zophie'}
>>> eggs = spam
1 >>> spam['name'] = 'Al'  
>>> spam
{'name': 'Al'}
>>> eggs  
2 {'name': 'Al'}

ومنه نجد أن التغييرات على المتغير spam في السطر 1 قد ظهرت أيضًا على المتغير eggs في السطر 2، وسبب ذلك أن كلاهما يتبع لنفس الكائن.

مفهوم المتغيرات المجرد: الصندوق BOX مقابل العنوان LABEL

تستخدم الكثير من الكتب التمهيدية مصطلح "الصناديق" بمثابة مفهوم مجرد للمتغيرات، ويُعد الأمر بسيطًا جدًا، فمن السهل فهم المتغيرات على أنها صناديق تُخزَّن فيها القيم كما في الشكل 1، إلا أن هذا المفهوم يتهاوى لدى التفكير من وجهة النظر المرجعية، فمثلًا المتغيرين spam و eggs السابقين لا يخزنان قاموسين منفصلين (نسختين من نفس القاموس) بل يخزنان مرجعًا في ذاكرة الحاسوب لنفس القاموس.

شكل 1: تفيد العديد من المراجع بأنه من الممكن فهم المتغيرات على أنها صناديق تحتوي على قيم

المتغيرات في بايثون من الناحية التقنية هي مراجع وليست حاويات containers للقيم، وذلك بغض النظر عن نوع البيانات التي تحتويها. رغم بساطة مفهوم الصندوق إلا أنه منقوص، فبدلًا من فهم المتغيرات على أنها صناديق، يُفضّل فهمها مثل عناوين للكائنات في الذاكرة، والشكل 2 التالي يبين العناوين لأمثلة المتغيرين spam و eggs السابقين.

شكل 2: من الممكن أيضًا فهم المتغيرات مثل عناوين للقيم

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

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

يمكن استخدام العامل is لمقارنة فيما إذا كان لكائنين نفس الهوية، وبالمقابل يمكن استخدام العامل == للتحقق فقط من كون قيمتي الكائنين متطابقتين، وبالتالي التعبير x is y مكافئ لنظيره (id(x) == id(y. لنكتب ما يلي في الصدفة التفاعلية لنلاحظ الفرق:

>>> spam = {'name': 'Zophie'}  
1 >>> eggs = spam
>>> spam is eggs  
True
>>> spam == eggs  
True
2 >>> fish = {'name': 'Zophie'}  
>>> spam == fish  
True
>>> spam is fish  
False

إذ يشير المتغيران spam وeggs إلى نفس كائن القاموس (في السطر 1)، وبالتالي فهما متساويان بالقيمة والهوية.، بينما يشير المتغير fish إلى كائن قاموس آخر (في السطر 2)، رغم كونه يتضمن بيانات مطابقة لتلك الموجودة في المتغيرين spam و eggs. يعني تطابق البيانات أن للمتغير fish نفس القيمة كما في المتغيرين spam و eggs، إلا أنهما كائنان مختلفان بهويتين مختلفتين.

العناصر Items

ندعو في بايثون الكائن الموجود ضمن كائن حاوية مثل قائمة أو قاموس بالعنصر، فعلى سبيل المثال، السلسة النصية ضمن القائمة ['dog', 'cat', 'moose'] هي كائنات ولكننا ندعوها أيضًا بالعناصر.

الثابت Immutable والمتغير Mutable

كما لاحظنا سابقًا، تمتلك كل الكائنات في بايثون قيمة ونوع بيانات وهوية، ويمكن منها تغيير القيمة فقط، وبما أننا نستطيع تغيير قيمة الكائن فهو كائن متغيّر؛ أما إذا كانت قيمته غير متغيرة فندعوه بالكائن الثابت. يعرض الجدول 2 قائمةً ببعض أنواع البيانات الثابتة والمتغيرة في بايثون.

جدول 2: بعض أنواع البيانات الثابتة والمتغيرة في بايثون

فلو أعدت الكتابة في متغير ما، قد يبدو لك أنك قد غيرت قيمة الكائن الخاص به، كما في المثال التالي في الصدفة التفاعلية:

>>> spam = 'hello'
>>> spam
'hello'
>>> spam = 'goodbye'
>>> spam
'goodbye'

لكننا لم نغيّر هنا قيمة الكائن 'hello' من 'hello' إلى 'goodbye'، فهما كائنان منفصلان، وكل ما فعلناه في الشيفرة السابقة هو مجرّد جعل المتغير spam يشير إلى الكائن 'goodbye' بدلًا من 'hello'، ويمكن التحقق من صحة أنهما فعلًا كائنين مستقلين باستخدام الدالة ()id للحصول على هوية كل منهما:

>>> spam = 'hello'
>>> id(spam)
40718944
>>> spam = 'goodbye'
>>> id(spam)
40719224

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

>>> spam = ['cat', 'dog']
>>> id(spam)
33805576
1 >>> spam.append('moose')
2 >>> spam[0] = 'snake'
>>> spam
['snake', 'dog', 'moose']
>>> id(spam)
33805576

تعمل كلًا من الدالة ()append (في السطر 1) وعملية الإسناد للعنصر (في السطر 2) على تعديل قيمة القائمة في مكانها (من أجل نفس الكائن بنفس الهوية)؛ فقد تغيرت قيمة القائمة، إلا أن هويتها قد بقيت كما هي 33805576؛ إما في حال استخدام العامل + لبناء تسلسل القائمة، فإننا ننشئ كائنًا جديدًا (ذو هوية جديدة) بديلًا عن ذلك السابق على النحو التالي:

>>> spam = spam + ['rat']
>>> spam
['snake', 'dog', 'moose', 'rat']
>>> id(spam)
33840064

ومنه نجد أن بناء تسلسل القائمة وفق الطريق السابقة (باستخدام العامل +) قد أنشأ قائمة جديدة بهوية جديدة، وبمجرد حدوث ذلك يُحرّر مُجمّع المهملات القائمة القديمة من الذاكرة. لمعرفة التوابع والعمليات التي تعدل قيم الكائنات مع الحفاظ على هويتها وتلك التي تغيرها، عليك الرجوع إلى توثيق بايثون، ولكن يمكنك أخذ القاعدة التالية بالحسبان: إذا رأيت قيمةً مجردةً ضمن الشيفرة المصدرية، مثل ['rat'] في المثال السابق، فعندها سينشئ بايثون كائنًا جديدًا بهوية جديدة غالبًا، في حين أن التوابع المُستدعاة مع استخدام الكائن بمثابة وسيط لها، مثل التابع ()append، فغالبًا ما تعدّل قيمة الكائن مُحافظةً على هويته.

في حال التعامل مع أنواع البيانات الثابتة مثل الأعداد الصحيحة والسلاسل النصية والصفوف، ستكون عمليات الإسناد هي الأبسط. لنكتب على سبيل المثال ما يلي في الصدفة التفاعلية:

>>> fish = 'Goodbye'
>>> id(fish)
33827584
1 >>> fish = 'Hello'
>>> id(fish)
33863820
2 >>> fish = fish + ', world!'
>>> fish
'Hello, world!'
>>> id(fish)
33870056
3 >>> fish[0] = 'J'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object does not support item assignment

السلاسل النصية ثابتة، بمعني أنه من غير الممكن تغيير قيمة السلسلة نفسها، ففي حين يبدو أننا قد غيرنا قيمة السلسة النصية في المتغير fish من القيمة 'Goodbye' إلى القيمة 'Hello' (في السطر رقم 1)، إلا أنّه في الواقع قد غيّرنا قيمته إلى كائن سلسلة نصية جديدة ذو هوية جديدة؛ وعلى نحوٍ مشابه، ينشئ التعبير البرمجي باستخدام بناء تسلسل القائمة كائن قائمة جديد (كما في السطر 2) ذو هوية جديدة. لا يُسمَح في الإصدار 3 من بايثون تغيير السلاسل النصية باستخدام عمليات الإسناد دون تغيير هوية الكائن.

تُعرّف قيمة الصف وفقًا للكائنات التي يحتويها وترتيب هذه الكائنات؛ فالصفوف هي تسلسلات من الكائنات الثابتة التي تحصر القيم في أقواس، ما يعني أنه من غير الممكن تغيير العناصر الموجودة في الصف، كما في المثال التالي:

>>> eggs = ('cat', 'dog', [2, 4, 6])
>>> id(eggs)   
39560896
>>> id(eggs[2]) 
40654152
>>> eggs[2] = eggs[2] + [8, 10]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment

أما في حال تواجد قائمة متغيرة ضمن الصف الثابت، فستبقى متغيّرة دون تغيير هويتها، كما في المثال التالي:

>>> eggs[2].append(8)
>>> eggs[2].append(10)
>>> eggs
('cat', 'dog', [2, 4, 6, 8, 10])
>>> id(eggs)    
39560896
>>> id(eggs[2]) 
40654152

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

يعد كل محترفي بايثون الصف ثابتًا، ويعتمد أمر تسمية بعض الصفوف بأنها متغيرة على تعريفك وفهمك لها.

الشكل 3: رغم كون مجموعة الكائنات ضمن الصف ثابتة، إلا أن المتغيرات نفسها قادرة على التغير.

الفهارس Indexes والمفاتيح Keys والقيم المعماة Hashes

قوائم وقواميس بايثون هي قيم يمكن أن تحتوي على قيم أخرى متعددة، ويمكن للوصول إلى هذه القيم استخدام عامل الفهرس المكون من زوج من الأقواس المعقوفة وعدد صحيح يسمى الفهرس لتحديد القيمة المراد الوصول إليها، ولنبيّن كيفية استخدام الفهرس مع القائمة، سنكتب ما يلي في الصدفة التفاعلية:

>>> spam = ['cat', 'dog', 'moose']
>>> spam[0]
'cat'
>>> spam[-2]
'dog'

في المثال السابق، الرقم 0 هو فهرس، إذ أن الفهرس الأول هو 0 وليس 1، إذ تستخدم بايثون ومعظم لغات البرمجة الصفر بدايةً للفهارس، أما اللغات التي تعتمد 1 بدايةً للفهارس فهي نادرة وأشهرها لغتي Lua و R، كما أن بايثون تدعم الفهارس السالبة، إذ يشير مثلًا "1-" إلى العنصر الأخير في القائمة، في حين يشير "2-" إلى العنصر ما قبل الأخير، وهكذا. يمكن فهم الفهرس السالب بالشكل [spam[–n مكافئًا لاستخدام [spam[len(spam) – n.

ملاحظة: قال عالم الحاسوب والمغني وكاتب الأغاني ستان كيلي-بوتل Stan Kelly-Bootle مرة مازحًا: أيجب أن تبدأ فهارس المصفوفات من الصفر أو الواحد؟ كان اقتراحي بمثابة حلٍ وسطي أن تبدأ من 0.5 ولكنه رفض دون سبب وجيه على ما أعتقد.

يمكن استخدام عامل الفهرس على السلسلة المجردة كما هي، رغم كون الأقواس المعقوصة الخاصة بالفهرس قد تبدو غريبة وغير ضرورية في هذه الحالة، كما في المثال:

>>> ['cat', 'dog', 'moose'][2]
'moose'

: كما يمكن استخدام الفهارس على قيم غير القوائم، مثل السلاسل النصية بغية الحصول على محارف معينة من السلسلة، على النحو التالي:

>>> 'Hello, world'[0]
'H'

أما قواميس بايثون، فتُرتّب على هيئة أزواج "مفتاح-قيمة"، على النحو التالي:

>>> spam = {'name': 'Zophie'}
>>> spam['name']
'Zophie'

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

>>> hash('hello')
-1734230105925061914
>>> hash(42)
42
>>> hash(3.14)
322818021289917443
>>> hash((1, 2, 3))
2528502973977326415
>>> hash([1, 2, 3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

تُستخدم المفاتيح المعماة لإيجاد العناصر المخزنة في القواميس وغيرها من هياكل البيانات، ولهذا لا يمكن استخدام قائمة متغيرة مثل مفتاح لقاموس:

>>> d = {}
>>> d[[1, 2, 3]] = 'some value'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

تختلف القيمة المعماة عن الهوية، فلو كان لدينا كائنان مختلفان يتضمنان نفس القيمة، سيكون لكل منهما هويته الخاصة، أما القيمة المعماة فستكون نفسها لكليهما. لنكتب على سبيل المثال ما يلي في الصدفة التفاعلية:

>>> a = ('cat', 'dog', 'moose')
>>> b = ('cat', 'dog', 'moose')
>>> id(a), id(b)
(37111992, 37112136)
1 >>> id(a) == id(b)
False
>>> hash(a), hash(b)
(-3478972040190420094, -3478972040190420094)
2 >>> hash(a) == hash(b)
True

يمتلك الصفان المُشار إليهما بواسطة a و b هويتين مختلفتين كما هو موضح في السطر 1 من الشيفرة السابقة، ولكن كونهما يحتويان على قيمتين متطابقتين فالقيم المعماة لهما متساوية كما هو موضح في السطر 2. يكون الصف قابلًا للتعمية في حال احتوائه على عناصر قابلة للتعمية، وبما أنه لا يمكن استخدام سوى عناصر قابلة للتعمية مثل مفاتيح للقواميس، فمن غير الممكن استخدام صفٍ يحتوي على قائمة غير قابلة للتعمية مثل مفتاح. لنكتب ما يلي ضمن الصدفة التفاعلية:

>>> tuple1 = ('cat', 'dog')
>>> tuple2 = ('cat', ['apple', 'orange']) 
>>> spam = {}
1 >>> spam[tuple1] = 'a value'
2 >>> spam[tuple2] = 'another value'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

نلاحظ أن الصف tuple1 قابل للتعمية، في حين أن الصف tuple2 يتضمن قائمة فهو غير قابل للتعمية مثلها.

أنواع الحاويات Containers والسلاسل المفهرسة بأرقام Sequences والمفهرسة بمفاتيح Mapping والمجموعات set

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

السلسلة المفهرسة بأرقام هي كائن يحتوي على أي من أنواع بيانات الحاويات، ذو قيم مرتبة يمكن الوصول إليها اعتمادًا على فهارس من أعداد صحيحة. السلاسل النصية والصفوف والقوائم والمتغيرات من النوع byte هي أنواع بيانات من نوع السلاسل المفهرسة بأرقام، إذ يمكن الوصول إلى القيم في هذا النوع من الكائنات باستخدام عامل الفهرسة (القوس المعقوف [ و ])، كما يمكن تمرير الفهرس إلى الدالة ()len. يُقصد بكلمة "مرتبة" وجود ما يمكن تسميته القيمة الأولى والثانية وهكذا، فعلى سبيل المثال، لا يمكن أن تكون قيمتا القائمتين التاليتين متساويتين لأنهما مرتبتان على نحوٍ مختلف:

>>> [1, 2, 3] == [3, 2, 1]
False

السلسلة المفهرسة بمفاتيح mapping هي كائن يحتوي على أي من أنواع بيانات الحاويات الذي يستخدم المفاتيح عوضًا عن الفهرس. يمكن لهذا النوع من السلاسل أن يكون مرتبًا أو غير مرتبًا؛ فالقواميس في الإصدار 3.4 من بايثون والإصدارات الأقدم غير مرتبة لعدم وجود ما يسمى أول أو آخر زوج "مفتاح-قيمة" في القاموس، كما في المثال التالي:

>>> spam = {'a': 1, 'b': 2, 'c': 3, 'd': 4}  # This is run from CPython 3.5.
>>> list(spam.keys())
['a', 'c', 'd', 'b']
>>> spam['e'] = 5
>>> list(spam.keys())
['e', 'a', 'c', 'd', 'b']

لا توجد ضمانات للحصول على العناصر من القواميس بترتيب متسق في الإصدارات القديمة من بايثون، ونتيجةً للطبيعة غير الترتيبية للقواميس، سيكون لقاموسين مجردين يحتويان على نفس أزواج "مفتاح-قيمة" ولكن بترتيب مختلف قيمتان متساويتان:

>>> {'a': 1, 'b': 2, 'c': 3} == {'c': 3, 'a': 1, 'b': 2}
True

ولكن بدءًا من الإصدار 3.6 من المفسر CPython أصبحت القواميس تحتفظ بترتيب إدخال أزواج "مفتاح قيمة"، كما في المثال التالي:

>>> spam = {'a': 1, 'b': 2, 'c': 3, 'd': 4}  # This is run from CPython 3.6.
>>> list(spam)
['a', 'b', 'c', 'd']
>>> spam['e'] = 5
>>> list(spam)
['a', 'b', 'c', 'd', 'e']

وتعد هذه إحدى الميزات الموجودة في الإصدار 3.6 من المفسّر CPython وليست موجودة في كافة مفسرات الإصدار 3.6 من بايثون، بينما تدعم كافة مفسرات الإصدار 3.7 من بايثون القواميس الترتيبية، والتي أصبحت معيارية في لغة بايثون في الإصدار 3.7. إلا أن حقيقة كون قاموس ما ترتيبي لا يعني أنه من الممكن الوصول إلى عناصره باستخدام فهارس من أعداد صحيحة، فمثلًا لا يُقيّم التعبير [spam[0 على أنه العنصر الأول من القاموس الترتيبي (فيما عدا حالة كون مفتاح العنصر الأول من القاموس هو فعلًا 0). تعد القواميس الترتيبية أيضًا متطابقة إذا كانت تحتوي على نفس أزواج "مفتاح-قيمة"، حتى ولو كانت هذه الأزواج بترتيب مختلف في كل قاموس.

تتضمّن الوحدة collections العديد من السلاسل المفهرسة بمفاتيح الأخرى بما يتضمن OrderedDict (والتي تمثّل القواميس التي تحافظ على الترتيب دائمًا) و ChainMap (المُستخددمة لتجميع عدة قواميس معًا) و Counter (التي تُخزّن العناصر مثل مفاتيح للقواميس وعددها على أنها قيم فيه) و UserDict، وجميعها موصوفة ضمن توثيق بايثون.

التوابع السحرية

التوابع السحرية والتي تسمّى Dunder methods أو magic methods هي توابع خاصة في بايثون تبدأ أسماء كل منها وتنتهي بشرطتين سفليتين، وتُستخدم هذه التوابع لزيادة تحميل العامل. يأتي مصطلح Dunder اختصارًا للعبارة double underscore أي "شرطتين سفليتين". لعل أشهر التوابع السحرية هو ()__int__ والتي تقرأ بالشكل "dunder init dunder" أي "شرطتان سفليتان int شرطتان سفليتان" أو فقط "int"، والذي يعمل على تهيئة الكائنات. تتضمن بايثون عشراتٍ من التوابع السحرية.

الوحدات والحزم

الوحدة module هي برنامج بايثون تكون برامج بايثون الأخرى قادرةً على استيراده وبالتالي استخدام شيفرته. تسمّى مجموعة الوحدات الموجودة افتراضيًا في بايثون متجمعةً باسم مكتبة بايثون المعيارية، كما من الممكن إنشاء وحدات خاصة بك. إذا حفظت برنامجًا ما باسم "spam.py" على سبيل المثال، فمن الممكن تشغيل أمر الاستيراد import spam.py للوصول إلى الدوال والأصناف والمتغيرات عالية المستوى للبرنامج spam.py.

الحزمة Package هي مجموعة من الوحدات التي نُشكّلها عبر إنشاء ملف باسم "init.py" ضمن المجلد المطلوب، إذ نستخدم اسم هذا المجلد اسمًا للحزمة، ويمكن أن تحتوي الحزم على وحدات متعددة (وهي ملفات ذات امتداد "py.") أو حتى حزم أخرى (أي مجلدات أخرى تحتوي على ملفات "init.py").

الكائنات من الدرجة الأولى First-Class Objects والقابلة للاستدعاء Callables

لا تقتصر الأشياء القابلة للاستدعاء في بايثون على الدوال والتوابع، بل أي كائن يتضمّن عامل الاستدعاء -أي رمز القوسين الهلاليين ()- هو كائن قابل للاستدعاء. على سبيل المثال، لو كان لدينا التعبير ()def hello، يمكن فهم هذه الشيفرة على أنها متغير يدعى hello مُتضمنًا كائن دالة، إذ سيستدعي استخدام عامل الاستدعاء لهذا المتغير الدالة في المتغير بالشكل: ()hello.

الأصناف classes هي من مفاهيم لغات البرمجة كائنية التوجه، ويمثّل الصنف مثالًا على كائن قابل للاستدعاء دون أن يكون دالة أو تابع، فعلى سبيل المثال، يمكن استدعاء صنف التاريخ date الموجود في الوحدة datatime باستخدام عامل الاستدعاء كما في الشيفرة (datetime.date(2020, 1, 1، وبمجرد استدعاء كائن الصنف، تعمل الشيفرة الموجودة ضمن التابع ()__int__ من الصنف.

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

>>> def spam():
...     print('Spam! Spam! Spam!')
...
>>> spam()
Spam! Spam! Spam!

كما يمكن إسناد كائن الدالة ()spam إلى متغيراتٍ أخرى، وبمجرد استدعاء المتغير الذي أسندنا الدالة إليه، ينفذ بايثون هذه الدالة:

>>> eggs = spam
>>> eggs()
Spam! Spam! Spam!

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

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

>>> def callTwice(func):
...     func()
...     func()
...
>>> callTwice(spam)
Spam! Spam! Spam!
Spam! Spam! Spam!

كما يمكن الاكتفاء باستدعاء الدالة ()spam مرتين بكتابتها مرتين في الشيفرة المصدرية، إلا أنه يمكن تمرير التابع المراد استدعائه مرتين إلى الدالة ()callTwicw عوضًا عن كتابة اسم الدالة مرتين في الشيفرة المصدرية.

الخلاصة

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

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

ستجد دومًا أن استخدام المصطلحات يختلف من لغة لأخرى وحتى من مبرمج لآخر، وستغدو معتادًا أكثر على المصطلحات مع الخبرة والبحوثات المتكررة على الإنترنت.

ترجمة -وبتصرف- لجزء من الفصل السابع "المصطلحات البرمجية" من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigart.

اقرأ أيضًا

• المقال السابق: الطرق البايثونية في استخدام قواميس بايثون ومتغيراتها وعاملها الثلاثي
• مفهوم الدوال Functions في البرمجة
• كيف تتعلم البرمجة: نصائح وأدوات لرحلتك في عالم البرمجة
• تعلم البرمجة

سنقدم في هذا المقال العديد من الطرق الشائعة لكتابة شيفرات بايثون الاصطلاحية إلى جانب نظيراتها من الطرق غير البايثونية فيما يتعلق بقواميس بايثون والتعامل مع المتغيرات وعاملها الثلاثي.

تُعد القواميس dictionaries نواة العديد من برامج بايثون نظرًا للمرونة التي توفرها أزواج القيم المفتاحية key-value pairs عبر ربط أجزاء البيانات ببعضها بعضًا، وبالتالي من المفيد أن تتعلم حول اصطلاحات قواميس بايثون الأكثر استخدامًا في الشيفرات، ويمكنك مراجعها بقراءة مقال فهم القواميس في بايثون.

استخدام التابعين ()get و ()setdefault للتعامل مع القواميس

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

>>> # Unpythonic Example
>>> numberOfPets = {'dogs': 2}
>>> if 'cats' in numberOfPets: # Check if 'cats' exists as a key.
...     print('I have', numberOfPets['cats'], 'cats.')
... else:
...     print('I have 0 cats.')
...
I have 0 cats.

تتحقق الشيفرة السابقة من وجود السلسلة النصية cats مثل مفتاح ضمن القاموس المسمى numberOfPets؛ فإذا كانت كذلك فعلًا، يُطبع محتوى القاموس الموافق لهذا المفتاح باستخدام التعليمة ['numberOfPets['cats مثل جزء من الرسالة المعروضة للمستخدم باستخدام الدالة ()print؛ وفي حال عدم وجود هذا المفتاح تُطبع عبارة باستخدام دالة ()print أخرى دون الوصول إلى القاموس numberOfPetsكون المفتاح غير موجود وبالتالي لا تسبب بوقوع الخطأKeyError`.

تمتلك قواميس بايثونتابع ()get، الذي يسمح بتحديد قيمة افتراضية لتعاد في حال طلب مفتاح غير موجود في القاموس. والشيفرة البايثونية التالية تكافئ الشيفرة في المثال السابق:

>>> # Pythonic Example
>>> numberOfPets = {'dogs': 2}
>>> print('I have', numberOfPets.get('cats', 0), 'cats.')
I have 0 cats.

يتحقق الاستدعاء (numberOfPets.get('cats', 0 من كون المفتاح cats موجودًا في القاموس numberOfPets، فإذا كان موجودًا فعلًا يعيد الاستدعاء القيمة من القاموس الموافقة للمفتاح cats، وإلا يعيد الاستدعاء الوسيط الثاني وهو في حالتنا 0. إذًا، يمثّل استخدام التابع ()get لتحديد قيمة افتراضية لتعاد في حال استدعاء مفتاح غير موجود في القاموس طريقةً أقصر وأكثر مقروئية من استخدام العبارة الشرطية if-else.

قد ترغب بالمقابل بتعيين قيمة افتراضية في حال عدم وجود مفتاح ما. على سبيل المثال، بفرض أن القاموس numberOfPets لا يتضمن المفتاح 'cats'، ستتسبب التعليمة numberOfPets['cats'] += 10 بخطأ من النوع KeyError، وقد ترغب بإضافة شيفرة مهمتها التحقق من غياب مفتاح محدد مُعينةً قيمة افتراضية على النحو التالي:

>>> # Unpythonic Example
>>> numberOfPets = {'dogs': 2}
>>> if 'cats' not in numberOfPets:
...     numberOfPets['cats'] = 0
...
>>> numberOfPets['cats'] += 10
>>> numberOfPets['cats']
10

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

>>> # Pythonic Example
>>> numberOfPets = {'dogs': 2}
>>> numberOfPets.setdefault('cats', 0) # Does nothing if 'cats' exists.
0
>>> numberOfPets['cats'] += 10
>>> numberOfPets['cats']
10

فبدلًا من استخدام جملة if شرطية للتحقق من وجود مفتاح ما في قاموس وتعيين قيمة افتراضية في حال غيابه، استخدم التابع ()setdefault.

استخدام الصنف collections.defaultdict لتعيين قيم القواميس الافتراضية

يتيح استخدام الصنف collections.defaultdict إمكانية التخلص التام من أخطاء KeyError، إذ يُمكّنك من إنشاء قاموس افتراضي عن طريق استيراد الوحدة collections واستدعاء الدالة ()collections.defaultdict مُمررًا إليها نمط معطيات تختاره ليكون قيمةً افتراضية. على سبيل المثال، في حال تمرير الدالة int مثل وسيط إلى الدالة ()collections.defaultdict تكون قد أنشأت كائنًا شبيهًا بالقاموس dictionary-like object يستخدم القيمة 0 قيمةً افتراضية في حال طلب مفاتيح غير موجودة في القاموس. دعنا نكتب التالي في الصدفة التفاعلية:

>>> import collections
>>> scores = collections.defaultdict(int)
>>> scores
defaultdict(<class 'int'>, {})
>>> scores['Al'] += 1 # No need to set a value for the 'Al' key first.
>>> scores
defaultdict(<class 'int'>, {'Al': 1})
>>> scores['Zophie'] # No need to set a value for the 'Zophie' key first.
0
>>> scores['Zophie'] += 40
>>> scores
defaultdict(<class 'int'>, {'Al': 1, 'Zophie': 40})

مرّرنا في الشيفرة السابقة الدالة ()int ولم نستدعيها، وهذا سبب إهمالنا لأقواسها إذ كتبناها بالشكل int ضمن استدعاء الدالة (collections.defaultdict(int. يمكن تمرير الدالة list مثل وسيط وبالتالي استخدام قائمة فارغة بمثابة قيمة افتراضية للقاموس، كما في المثال التالي:

>>> import collections
>>> booksReadBy = collections.defaultdict(list)
>>> booksReadBy['Al'].append('Oryx and Crake')
>>> booksReadBy['Al'].append('American Gods')
>>> len(booksReadBy['Al'])
2
>>> len(booksReadBy['Zophie']) # The default value is an empty list.
0

إذًا، في الحالات التي نحتاج فيها إلى قيمة افتراضية لكل احتمالية ممكنة للمفاتيح، فمن الأسهل استخدام الدالة ()collections.defaultdict بدلًا من استخدام قاموس عادي واستدعاء التابع ()setdefault.

استخدام القواميس بدلا من العبارة Switch

تمتلك لغات البرمجة مثل لغة جافا العبارة البرمجية switch، والتي تعد أحد أنواع العبارة الشرطية if-elif-else، إذ أنها تشغِّل الشيفرة بناءً على القيمة التي يتضمنها متغير معين من بين مجموعة قيم، أما لغة بايثون فلا تتضمن العبارة switch ما يجعل مبرمجي بايثون يكتبون في بعض الحالات شيفراتٍ كما في المثال التالي، والذي يشغّل مجموعة من تعليمات الإسناد على ضوء القيمة التي يتضمنها المتغير season من بين مجموعة قيم، على النحو التالي:

# All of the following if and elif conditions have "season ==":
if season == 'Winter':
    holiday = 'New Year\'s Day'
elif season == 'Spring':
    holiday = 'May Day'
elif season == 'Summer':
    holiday = 'Juneteenth'
elif season == 'Fall':
    holiday = 'Halloween'
else:
    holiday = 'Personal day off'

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

holiday = {'Winter': 'New Year\'s Day',
           'Spring': 'May Day',
           'Summer': 'Juneteenth',
           'Fall':   'Halloween'}.get(season, 'Personal day off')

تتضمن الشيفرة السابقة تعليمة إسناد واحدة، إذ تمثّل القيمة المُخزّنة في المتغير holiday القيمة المعادة من استدعاء التابع ()get، الذي يعيد القيمة الموافقة للمفتاح المُعيّن في المتغير season، وفي حال كون المفتاح المطلوب غير موجود، سيعيد التابع ()get القيمة الافتراضية 'Personal day off'. جعل استخدام قاموس من الشيفرة مختصرة، إلا أنها قد تكون أصعب قليلًا للقراءة، ويعود القرار حول استخدامها من عدمه لك.

التعابير الشرطية: عامل بايثون الثلاثي القبيح

تعمل العوامل الثلاثية Ternary operators (والتي تُسمّى في بايثون رسميًا بالتعابير البرمجية الشرطية أو تعابير الانتقاء الثلاثية) على تقييم تعبير ما إلى إحدى قيمتين بناءً على شرط ما، وهذا ما نفعله عادةً باستخدام التعبير البايثوني if-else، على النحو التالي:

>>> # Pythonic Example
>>> condition = True
>>> if condition:
...     message = 'Access granted'
... else:
...     message = 'Access denied'
...
>>> message
'Access granted'

تعني كلمة "ثلاثي Ternary" ببساطة أن العامل يستقبل ثلاثة مدخلات، إلا أن مرادفها في عالم البرمجة هو "التعبير الشرطي". تقدّم التعابير الشرطية صيغةً مختصرة تُكتب ضمن سطر واحد، وهذا الأمر مناسب لهذا النمط الثلاثي، وتُنفّذ هذه التعابير في بايثون من خلال توزيع معيّن لكل من الكلمتين المفتاحيتين ifو else، كما في المثال التالي:

>>> valueIfTrue = 'Access granted'
>>> valueIfFalse = 'Access denied'
>>> condition = True
1 >>> message = valueIfTrue if condition else valueIfFalse
>>> message
'Access granted'
2 >>> print(valueIfTrue if condition else valueIfFalse)
'Access granted'
>>> condition = False
>>> message = valueIfTrue if condition else valueIfFalse
>>> message
'Access denied'

يُقيّم التعبير ذو الرقم 1 إلى القيمة الموافقة للوسيط valueIfTrue في حال كون متغير الشرط condition محققًا، أي مُقيّم على أنه True؛ أما في حال كونه غير محقق، أي أنه مُقيّم على أنه False فيُقيّم التعبير إلى القيمة الموافقة للوسيط valueIfFalse. وصف مبتكر لغة بايثون هذا التعبير مازحًا بأنه "قبيح عمدًا intentionally ugly"، إذ تضع معظم لغات البرمجة المُتضمنة العوامل الثلاثية الشرط بدايةً متبوعًا بالتعليمات المطلوبة في حال تحققه ثم تلك المطلوبة في حال عدم تحققه، ولكن يمكن -مع هذه الطريقة- استخدام تعبير شرطي في أي موضع نريد مكان أي قيمة أو تعبير، حتى مثل وسيط لإحدى الدوال كما هو الحال في السطر 2 من الشيفرة السابقة.

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

condition and valueIfTrue or valueIfFalse

إلى القيمة الموافقة للتعبير valueIfTrue في حال تحقق الشرط وإلى valueIfFalse في حال عدم تحققه (ماعدا حالة خاصة مهمة). لاحظ المثال التالي:

>>> # Unpythonic Example
>>> valueIfTrue = 'Access granted'
>>> valueIfFalse = 'Access denied'
>>> condition = True
>>> condition and valueIfTrue or valueIfFalse
'Access granted'

ينطوي العامل الثلاثي الزائف هذا على خطأ غامض خاص يحدث عند كون قيمة التعبير valueIfTrue من النمط الخاطئ (بمعنى أنها 0 أو False أو None أو سلسلة نصية فارغة)، فعندها سيُقيّم التعبير بصورة غير متوقعة إلى القيمة الموافقة للتعبير valueIfFalse عند تحقُق الشرط.

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

ليست التعابير الشرطية بايثونية تمامًا وليست غير بايثونية في الوقت نفسه، ففي حال استخدمتها، تجنب تداخلها:

>>> # Unpythonic Example
>>> age = 30
>>> ageRange = 'child' if age < 13 else 'teenager' if age >= 13 and age < 18 else 'adult'
>>> ageRange
'adult'

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

التعامل مع قيم المتغيرات

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

الإسناد التسلسلي وعوامل المقارنة

في حال أردت التحقق من كون عدد ما ينتمي إلى مجال محدد، ستستخدم غالبًا العامل المنطقي and على النحو التالي:

# Unpythonic Example
if 42 < spam and spam < 99:

إلا أن بايثون تسمح بتسلسل عوامل المقارنة وبالتالي من الممكن الاستغناء عن العامل and. تكافئ الشيفرة التالية تلك المذكورة في المثال السابق:

# Pythonic Example
if 42 < spam < 99:

ينطبق الأمر ذاته على تسلسل عامل الإسناد =، إذ من الممكن تعيين عدد من المتغيرات إلى نفس القيمة ضمن سطر برمجي واحد، على النحو التالي:

>>> # Pythonic Example
>>> spam = eggs = bacon = 'string'
>>> print(spam, eggs, bacon)
string string string

يمكن استخدام العامل and للتحقق من كون المتغيرات الثلاث تخزّن فعلًا نفس القيمة، أو استخدام سلسلة من العامل == للتحقق من المساواة ببساطة أكبر.

>>> # Pythonic Example
>>> spam = eggs = bacon = 'string'
>>> spam == eggs == bacon == 'string'
True

ميزة تسلسل العوامل بسيطة، إلا أنها ذات فائدة كبيرة في بايثون، ولكن بالمقابل سيتسبب الاستخدام الخاطئ لها بالأخطاء.

التحقق من كون قيمة متغير تنتمي لمجموعة محددة من القيم

قد تصادف أحيانًا حالة معاكسة تمامًا لتلك الواردة في الفقرة السابقة: وهي التحقق من كون قيمة متغير ما هي واحدة من مجموعة قيم ممكنة، ومن الممكن إنجاز ذلك باستخدام العامل or كما في التعبير التالي:

spam == 'cat' or spam == 'dog' or spam == 'moose` 

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

>>> # Pythonic Example
>>> spam = 'cat'
>>> spam in ('cat', 'dog', 'moose')
True

لا تمتاز هذه الطريقة بالسهولة فحسب، بل إنها أسرع أيضًا من حيث الوقت اللازم.

الخلاصة

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

تمتلك القواميس التابعين ()get و ()setdefault بغية التعامل مع المفاتيح غير الموجودة، ولكن من الممكن استخدام قاموس من النوع collections.defaultdict لتخزين القيم الافتراضية للمفاتيح غير الموجودة.

لا تتضمن لغة بايثون العبارة switch، لكن يمثّل استخدام القواميس طريقةً مختصرة لتطبيق ما يكافئ استخدام العبارة switch دون الحاجة إلى استخدام عدد كبير من عبارات if-elif-else، كما يمكن استخدام العوامل الثلاثية عند الحاجة إلى تقييم شرط ما إلى إحدى قيمتين.

وتتحقق العوامل == من كون المتغيرات متساوية أم لا، في حين يتحقق العامل in من كون المتغير يمثل واحدة من مجموعة قيم ممكنة.

ترجمة -وبتصرف- لجزء من الفصل السادس "كتابة شيفرات بايثون" من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigart.

اقرأ أيضًا

• المقال السابق: كتابة شيفرات بايثون: صيغ شائعة الاستخدام على نحو خاطئ
• اتخاذ القرار: العبارات الشرطية والحلقات التكرارية في البرمجة
• فهم العمليات المنطقية في بايثون

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

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

سنقدم في هذا المقال العديد من الطرق الشائعة لكتابة شيفرات بايثون الاصطلاحية إلى جانب نظيراتها من الطرق غير البايثونية. فما يعد "بايثوني" قد يختلف من مبرمج لآخر.

مبادئ بايثون التوجيهية العشرون

مبادئ بايثون التوجيهية العشرون أو ما يعرف باسم "زن بايثون The Zen of Python" الموضوعة من قبل تيم بيترز Tim Peters تختص بتصميم لغة بايثون وبرامجها. وليس من الضروري أن تتبع في برامجك كامل هذه التوجيهات، إلا أنه من المفيد تذكرها دومًا. كما أنها تمثل هديةً مخفية أو طرفة كامنة تظهر لدى تشغيل الأمر import this كما يلي:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
--snip--

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

وبالنتيجة هذه المبادئ التوجيهية لا تتعدى كونها آراء يمكن للمبرمجين أن يؤيدوها أو يعارضوها. وكأي مجموعة من المبادئ الجيدة فإنها تناقض نفسها موفرةً أكبر قدر ممكن من المرونة. وفيما يلي تفسيري لهذه الحكم:

اقتباس

الجمال أفضل من القبح

Beautiful is better than ugly

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

اقتباس

التصريح أفضل من التضمين

Explicit is better than implicit

لنفرض أني كتبت الآن "القول مُفسّر لنفسه" كشرح لهذه الحكمة، أليس بالشرح المريع؟ كذلك الأمر بالنسبة للشيفرات، فمن المحبذ أن تتبع الأساليب المطولة الصريحة، متجنبًا إخفاء آليات عمل الشيفرة تحت قناع ميزات اللغة التي تتطلب معرفة عميقة بها لفهمها.

اقتباس

البساطة أفضل من التعقيد، المعقد أفضل من المعقد المتشعب

Simple is better than complex. Complex is better than complicated

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

اقتباس

السطحية أفضل من التداخل

Flat is better than nested

يميل المبرمجون لتنظيم شيفرتهم ضمن فئات، لاسيما تلك الفئات التي تتضمن فئات فرعية والتي تتضمن بدورها فئات فرعية أيضًا. ولا تضيف هذه البنى الهرمية عادةً إلى الشيفرة تنظيمًا بقدر ما تضيف له بيروقراطية. ولا بأس بأن تكتب شيفرتك ضمن إحدى الوحدات عالية المستوى أو ضمن بنية معطيات واحدة. ولكن إن بدت شيفرتك بالشكل ()spam.eggs.chicken.fish أو ['spam['eggs']['chicken']['fish، فاعلم أن شيفرتك شديدة التعقيد والتشعب.

اقتباس

التباعد أفضل من التقارب

Sparse is better than dense

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

print('\n'.join("%i bytes = %i bits which has %i possiblevalues." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))

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

اقتباس

للمقروئية أهميتها

Readability counts

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

اقتباس

الحالات الخاصة ليست خاصة لدرجة تسمح بكسر القواعد، رغم كون الواقع العملي غير مثالي

Special cases aren’t special enough to break the rules. Although practicality beats purity

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

اقتباس

الحل ليس بإسكات الأخطاء، ما لم تُسكّت عمدًا

Errors should never pass silently. Unless explicitly silenced

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

اقتباس

احذر اغراءات التخمين في رحلة كشف الغموض

In the face of ambiguity, refuse the temptation to guess

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

اقتباس

لابد من وجود طريقة واحدة واضحة لإنجاز الأمر، ومن المفضل وجود طريقة واحدة فقط

There should be one—and preferably only one—obvious way to do it

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

اقتباس

قد لا تكون الأمور واضحة بدايةً مالم تكن هولنديًا

Although that way may not be obvious at first unless you’re Dutch

هذه الحكمة عبارة عن طرفة، إشارةً لكون مبتكر بايثون جيدو فان روسوم هولندي الأصل.

اقتباس

أن تفعلها الآن أفضل من ألا تفعلها أبدًا، رغم كون عدم فعلها أبدًا أفضل من إلزامية فعلها في نفس اللحظة

Now is better than never. Although never is often better than *right* now

تشير هاتان الحكمتان لحقيقة كون الشيفرة التي تُنفّذ ببطء هي أسوأ وضوحًا من تلك التي تُنفّذ سريعًا. ولكن بالمقابل من الأفضل الانتظار بعض الوقت لحين تنفيذ برنامجك على أن يُنفّذ بسرعة وبنتائج خاطئة.

اقتباس

تعد الفكرة سيئة في حال كون شرح كيفية تنفيذها أمر عسير، وقد تكون الفكرة جيدة في حال كون شرح كيفية تنفيذها أمرًا يسيرًا

If the implementation is hard to explain, it’s a bad idea. If the implementation is easy to explain, it may be a good idea

تتعقد الكثير من الأمور بمرور الوقت، كالقوانين الضريبية والعلاقات العاطفية وكتب بايثون البرمجية! والأمر نفسه ينطبق على عالم البرمجيات. تذكرنا هاتان الحكمتان بحقيقة أنه في حال كون الشيفرة معقدة لدرجة تجعل من المستحيل للمبرمجين الآخرين فهمها وتنقيحها، فهي شيفرة سيئة. ولكن بالمقابل فإن سهولة شرح فكرة الشيفرة للآخرين لا يعني بالضرورة أنها ليست سيئة. فللأسف معرفة كيفية جعل الشيفرة بسيطة ما أمكن بطريقة مدروسة ليست بالمهمة السهلة.

اقتباس

استخدام نطاقات الأسماء فكرة رائعة - لنستخدمها!

Namespaces are one honking great idea—let’s do more of those

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

وككل الآراء في عالم البرمجة، قد لا تتفق والآراء المبينة أعلاه أو قد تعبّر عما هو مخالف لرأيك وموقفك، ولكن تذكر دائمًا بأن الجدالات حيال كيفية كتابة الشيفرات وما يعتبر منها بايثونيًا -وعلى خلاف ما تظنه- نادرًا ما يكون مثمرًا (ما لم تكن تؤلف كتابًا كاملًا مليئًا بالآراء البرمجية).

دورة تطوير التطبيقات باستخدام لغة Python

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

اشترك الآن

اعتد استخدام المسافات البادئة ذات المعنى

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

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

// Java Example
public static void main(String[] args) {
    System.out.println("Hello, world!");
}

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

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

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

>>> from __future__ import braces
SyntaxError: not a chance

لن تضاف الأقواس إلى بايثون على المدى المنظور.

صيغ شائعة الاستخدام على نحو خاطئ

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

استخدم الدالة ()enumerate بدلا من ()range

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

>>> animals = ['cat', 'dog', 'moose']
>>> for i in range(len(animals)):
...     print(i, animals[i])
...
0 cat
1 dog
2 moose

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

>>> # Pythonic Example
>>> animals = ['cat', 'dog', 'moose']
>>> for i, animal in enumerate(animals):
...     print(i, animal)
...
0 cat
1 dog
2 moose

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

>>> # Pythonic Example
>>> animals = ['cat', 'dog', 'moose']
>>> for animal in animals:
...     print(animal)
...
cat
dog
moose

فكل من استخدام الدالة ()enumerate والمرور المباشر على عناصر السلسلة هي أمور مفضلة على استخدام التركيب التقليدي (()range(len.

استخدام التعليمة with بدلا من الدالتين()open و()close

تعيد الدالة ()open كائن ملف يتضمّن التوابع اللازمة للقراءة من ملف أو الكتابة فيه، وعند انتهائك يعمل التابع ()close الخاص بكائن الملف على إتاحة الملف للبرامج الأخرى لتقرأ منه أو تكتب فيه. كما من الممكن استخدام كل من هاتين الدالتين منفردة، إلا أن هذه الطريقة ليست بايثونية. فعلى سبيل المثال، لنُدخل الشيفرات التالية في الصدفة التفاعلية بغية كتابة العبارة النصية "!Hello, World" ضمن الملف المسمى spam.txt:

>>> # Unpythonic Example
>>> fileObj = open('spam.txt', 'w')
>>> fileObj.write('Hello, world!')
13
>>> fileObj.close()

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

>>> # Unpythonic Example
>>> try:
...     fileObj = open('spam.txt', 'w')
...     eggs = 42 / 0    # A zero divide error happens here.
...     fileObj.close()  # This line never runs.
... except:
...     print('Some error occurred.')
...
Some error occurred.

فبمجرد الوصول إلى خطأ القسمة على صفر سينتقل التنفيذ مباشرةً إلى الكتلة except، متجاوزًا استدعاء الدالة ()close تاركًا بذلك الملف مفتوحًا، ما قد يؤدي بالنتيجة إلى أخطاء تلف الملفات file corruption لاحقًا، ومن الصعب تعقب الخطأ وتوقّع أن مصدره هو كتلة try.

وبدلًا من الطريقة السابقة من الممكن استخدام التعليمة with والتي تستدعي الدالة ()close تلقائيًا بمجرد انتهاء تنفيذ الكتلة with. وفيما يلي مثال مكتوب بطريقة بايثونية يؤدي نفس مهمة المثال الأول من هذه الفقرة:

>>> # Pythonic Example
>>> with open('spam.txt', 'w') as fileObj:
...     fileObj.write('Hello, world!')
…

فرغم عدم استدعاء الدالة ()close صراحةً، إلا أن التعليمةwith ستستدعيها نلقائيًا بمجرد انتهاء تنفيذ الكتلة البرمجية هذه.

استخدم المعامل is بدلًا من == للمقارنة مع القيمة الخالية None

يقارن معامل المساواة == قيمتي كائنين، في حين أن معامل التماثل is يقارن تطابق هويات الكائنات. فمن الممكن أن يتضمّن كائنين قيمًا متكافئة ولكن كونهما كائنان منفصلان فهذا يعني أن لكل منهما هويته المنفصلة عن الآخر. وعمومًا في حال مقارنة قيمة ما مع القيمة الخالية None استخدم دائمًا المعامل is عوضًا عن المعامل ==.

فقد يُقيّم التعبير spam==None على أنه صحيح True في بعض الحالات حتى في حال كون المتغير spam فارغًا بالمعنى المجرد، الأمر الناتج عن زيادة تحميل المعامل ==. في حين أن التعبير spam is None سيتحقق من كون القيمة في المتغير spam هي حرفيًا None، إذ أنّ None هي القيمة الوحيدة ضمن نمط المعطيات الخالية None Type، فلا يوجد سوى كائن خالٍ None Object واحد في أي برنامج بايثون. فإن عُيّن أحد المتغيرات ليكون خاليًا None، فعندها سيُقيّم التعبير is None دومًا على أنه صحيح True، وفيما يلي مثال على حالة زيادة تحميل المعامل:

>>> class SomeClass:
...     def __eq__(self, other):
...         if other is None:
...             return True
...
>>> spam = SomeClass()
>>> spam == None
True
>>> spam is None
False

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

ونهايةً، لا تستخدم المعامل is مع القيمتين True وFalse بل استخدم المعامل == لمقارنة هذه القيم، من قبيل spam == True أو Spam == False. والطريقة الأكثر شيوعًا في مثل هذه الحالات هي عدم استخدام المعامل والقيمة المنطقية بالمطلق، والاكتفاء بكتابة الشيفرة بالشكل :if spam أو :if not spam بدلًا من كتابة :if spam == True أو :if spam == False.

تنسيق السلاسل النصية

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

استخدم تنسيق السلاسل النصية الخام إذا تضمنت السلاسل عدة خطوط مائلة عكسية

تمكننا محارف الهروب escape characters من إدخال النصوص ضمن صياغة السلسلة النصية والتي يستحيل تضمينها فيها دون استخدامها. فعلى سبيل المثال لابد من استخدام محرف الهروب \ في العبارة Ahmad\'s chair لتُفسر علامة الاقتباس الثانية على أنها جزء من السلسلة النصية وليست على أنها علامة انتهاء السلسلة. ولكن ماذا لو أردنا بالفعل تضمين الرمز \ بحد ذاته ضمن السلسلة النصية؟ عندها يجب استخدامه بالشكل \\.

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

>>> # Unpythonic Example
>>> print('The file is in C:\\Users\\Al\\Desktop\\Info\\Archive\\Spam')
The file is in C:\Users\Al\Desktop\Info\Archive\Spam

أما باستخدام مفهوم السلاسل النصية الخام (لاحظ البادئة r) فسنحصل بالنتيجة على نفس السلسلة ولكن مع شيفرة ذات مقروئية أعلى:

>>> # Pythonic Example
>>> print(r'The file is in C:\Users\Al\Desktop\Info\Archive\Spam')
The file is in C:\Users\Al\Desktop\Info\Archive\Spam

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

نسق السلاسل النصية باستخدام السلاسل النصية التنسيقية F-Strings

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

'Hello, ' + name + '. Today is ' + day + ' and it is ' + weather + '.'

كما من الممكن استخدام مُحدّد التحويل ‎%s الذي يجعل من الصياغة أسهل بعض الشيء بالشكل:

'Hello, %s. Today is %s and it is %s.' % (name, day, weather)

وبالنتيجة ستعمل كلا الطريقتين على إدخال السلاسل النصية الموافقة مكان كل من المتغيرات name وday وweather في السلسلة النصية المجردة وصولًا إلى سلسلة نصية جديدة مثل:

'Hello, Al. Today is Sunday and it is sunny.'

يعمل التابع ()format الخاص بالسلاسل المحرفية على تمكين لغة تخصيص التنسيق المصغرة Format Specification Mini-Language والتي تتضمن استخدام أزواج الأقواس المعقوصة {} بطريقة مماثلة لفكرة استخدام مُحدّد التحويل s%، إلا أن هذه الطريقة تنطوي على شيء من التعقيد ما قد يُنتج شيفرة بمقروئية منخفضة، لذا لا أشجع استخدامها.

إلى أن جاء الإصدار 3.6 من بايثون بميزة السلاسل النصية التنسيقية f-strings (اختصارًا لعبارة format strings) التي توفر طريقة أكثر ملائمة لإنشاء سلاسل نصية تتضمن سلاسل نصية أخرى. وكما هو الحال مع السلاسل النصية الخام والتي نستخدم لإنشائها البادئة r قبل علامة الاقتباس الاستهلالية، نستخدم هنا البادئة f، وفيها نُضمّن أسماء المتغيرات المطلوبة ضمن أقواس معقوصة لاستبدال كل منها لاحقًا بالسلاسل النصية المُخزنة فيها، على النحو:

>>> name, day, weather = 'Al', 'Sunday', 'sunny'
>>> f'Hello, {name}. Today is {day} and it is {weather}.'
'Hello, Al. Today is Sunday and it is sunny.'

كما من الممكن تضمين تعابير برمجية كاملة في الأقواس المعقوصة، كما في المثال:

>>> width, length = 10, 12
>>> f'A {width} by {length} room has an area of {width * length}.'
'A 10 by 12 room has an area of 120.'

وفي حال رغبتك باستخدام أقواس معقوصة فعلية ضمن السلسلة النصية، يمنك الهروب من اعتبارها دلالة على استبدال المتغير ضمنها بقيمته من خلال استخدام زوج إضافي منها، على النحو:

>>> spam = 42
>>> f'This prints the value in spam: {spam}'
'This prints the value in spam: 42'
>>> f'This prints literal curly braces: {{spam}}'
'This prints literal curly braces: {spam}'

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

وجود هذه الطرق المتعددة يخالف الحكمة القائلة "لابد من وجود طريقة واحدة واضحة لإنجاز الأمر، ومن المفضل وجود طريقة واحدة فقط" من مبادئ بايثون التوجيهية العشرون، إلا أن السلاسل النصية التنسيقية f-strings قد جاءت كتطوير للغة بايثون (من وجهة نظري)، وكما أن أحد المبادئ التوجيهية يشير إلى أن "الواقع العملي غير مثالي"، فإن كنت تستخدم الإصدار 3.6 من بايثون وما بعده فاستخدم دومًا السلاسل النصية التنسيقية. أما في حال استخدامك للإصدارات الأقدم، فأنصحك باستخدام التابع ()format أو الاعتماد على محدد التحويل s%.

إنشاء نسخ ضحلة عن القوائم lists

من الممكن إنشاء سلاسل نصية أو قوائم جديدة من تلك الحالية باستخدام صياغة التجزئة، ولرؤية كيفية عملها اكتب التعليمات التالية في الصدفة التفاعلية:

>>> 'Hello, world!'[7:12] # Create a string from a larger string.
'world'
>>> 'Hello, world!'[:5] # Create a string from a larger string.
'Hello'
>>> ['cat', 'dog', 'rat', 'eel'][2:] # Create a list from a larger list.
['rat', 'eel']

نضع رمز النقطتين الرأسيتين : بين فهرسي عنصر البداية والنهاية للسلسلة الجديدة المراد إنشاؤها، ولدى إهمال وضع فهرس البداية قبل النقطتين الرأسيتين كما في المثال '[Hello, world!'[:5، فيُعيّن حينها افتراضيًا إلى القيمة 0، أما إذا أهملنا فهرس النهاية بعد النقطتين الرأسيتين كما في المثال [:cat', 'dog', 'rat', 'eel'][2']، فيُعيّن افتراضيًا إلى فهرس العنصر الأخير من السلسلة الأم.

أما إذا أهملت تعيين كلا الفهرسين، فسيتم تعيين فهرس البداية إلى 0 (أي بداية القائمة أو السلسلة) وفهرس النهاية إلى نهاية القائمة، الأمر الذي يمثل طريقة فعالة لإنشاء نسخة عن السلسلة:

>>> spam = ['cat', 'dog', 'rat', 'eel']
>>> eggs = spam[:]
>>> eggs
['cat', 'dog', 'rat', 'eel']
>>> id(spam) == id(eggs)
False

ومن الجدير بالملاحظة في المثال السابق أن هويات القائمتين spam وeggs مختلفتين رغم تطابق قيمهما، إذ أن السطر البرمجي [:]eggs = spam ينشئ نسخة ضحلة عن القائمة spam، في حين أن التعليمة eggs=spam ستنسخ فعليًا مرجع القائمة spam وتسنده إلى القائمة eggs، إلا أن استخدام التعليمة [:] قد يبدو غريبًا بعض الشيء، واستخدام الدالة ()copy من وحدة النسخ copy module لإنشاء نسخة ضحلة من القائمة تعد الطريقة الأعلى مقروئية:

>>> # Pythonic Example
>>> import copy
>>> spam = ['cat', 'dog', 'rat', 'eel']
>>> eggs = copy.copy(spam)
>>> id(spam) == id(eggs)
False

فمن المفضل معرفتك لهذه الصياغة الغريبة لحالات مصادفتك لشيفرات بايثون قد استخدمتها، أما في شيفراتك الخاصة، فلا ننصحك باستخدامها. وتذكر أن كلًا من [:] و ()copy.copy تُنشآن نسخًا ضحلة.

الخلاصة

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

ولعل حجر الأساس وجوهر الشيفرات البايثونية هو "مبادئ بايثون التوجيهية العشرون"، وهي عبارة عن توجيهات عامة للكتابة بلغة بايثون. إلا أن هذه الحكم العشرون اختيارية وليست إلزامية لكتابة شيفرات بايثون، ومع ذلك من الجيد تذكرها دومًا.

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

ورغم كون العديد من مبرمجي بايثون يستخدمون التركيب (()range(len للحلقات التكرارية، إلا أن الدالة ()enumerate توفّر منهجية أوضح للحصول على رقم الفهرس والقيمة الموافقة له لدى المرور على سلسلة ما. وكذلك الأمر بالنسبة للعبارة with الأوضح والأقل تسببًا بالأخطاء للتعامل مع الملفات مقارنةً باستدعاء التابعين ()open و()close يدويًا، إذ تضمن العبارة with استدعاء التابع ()close عند انتهاء التنفيذ وخروجه من الكتلة الخاصة بها.

ولدى بايثون العديد من الطرق للتعامل مع السلاسل النصية ومعالجتها، ولعل الطريقة الأقدم هي استخدام محدد التحويل s% لتحديد المواضع المراد تضمينها ضمن السلسلة الرئيسية كجزء منها، أما الطريقة الأحدث والتي غدت موجودة اعتبارًا من الأصدار 3.6 فهي استخدام السلاسل النصية التنسيقية f-strings، وتُستخدم من خلال البادئة f قبل السلسلة النصية المراد صياغتها وبحصر الأجزاء المراد تضمينها في السلسلة ضمن أقواس معقوصة.

أما الصيغة [:] المستخدمة لإنشاء نسخ ضحلة عن القوائم قد غدت قديمة نسبيَا وقد لا تعد طريقة بايثونية، إلا أنها قد غدت طريقة شائعة لإنشاء النسخ الضحلة بسرعة.

ترجمة -وبتصرف- لجزء من الفصل السادس "كتابة شيفرات بايثون" من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigart.

اقرأ أيضًا

• المقال السابق: خرافات حول ممارسات تجنب أخطاء محتملة في شيفرات لغة بايثون
• كيفية تنسيق النصوص في بايثون
• اكتشاف دلالات الأخطاء في شيفرات لغة بايثون

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

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

في هذا المقال سنعرفك على أهم مكتبات بايثون التي يستخدمها معظم المطورين أثناء تطوير مشاريعهم وتطبيقاتهم ونعطيك فكرة موجزة عن أهمية كل مكتبة منها وأبرز المميزات التي تقدمها لك.

ما معنى مكتبة بايثون؟

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

تخدم مكتبات بايثون معظم مجالات البرمجة فنظرًا لكونها لغة برمجة مفتوحة المصدر open source لذا يساهم الكثير من المطورين المتطوعين في تطوير هذه المكتبات وإتاحتها للاستخدام عبر الإنترنت وكل ما تحتاجه كمستخدم إلى تثبيت المكتبة واستيرادها في كود مشروعك وسيتاح لك الوصول إلى كل وظائفها.

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

num = [2, 4, 1, 5, 9]
n = len(num)
get_sum = sum(num)
mean = get_sum / n
print("Average = ",mean)

الآن لو أردنا لاستعانة بإحدى المكتبات التي توفر دالة جاهزة لحساب المتوسط سنجد العديد منها مثل مكتبة statistics و NumPy، على سبيل المثال سنستورد مكتبة NumPy في بداية الكود البرمجي كما يلي

import numpy

بعدها سنتمكن من كتابة الكود المكافئ للكود السابق لحساب المتوسط الحسابي بتعليمات أقل كما يلي:

num = [2, 4, 1, 5, 9]
mean = numpy.average(num)
print("Average = " ,mean)

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

أهم مكتبات بايثون للمشاريع الصغيرة

دعنا الآن نتعرف على أهم عشر مكتبات في لغة بايثون يمكنك استعمالها في المشاريع البرمجية المتنوعة:

• Dataset
• Beautiful Soup
• Requests
• Click
• Python Slugify
• Pluggy
• Datasette
• Envparse
• Pillow
• Tkinter

لنتعرف على مزيد من التفاصيل حول كل مكتبة من هذه المكتبات ونتعرف على وظيفتها الأساسية.

Dataset: مكتبة بايثون لحفظ البيانات في قاعدة البيانات بشكل سريع

تُستخدم مكتبة Dataset ععندما نحتاج إلى جمع البيانات وحفظها في قاعدة البيانات قبل أن نكتشف ما هو الشكل النهائي لجداول قاعدة البيانات. حيث تُعتبر Dataset بسيطة ولكنها مع ذلك توفر API قوي يقدم طريقة سهلة لحفظ البيانات داخلها ثم تصنيفها لاحقًا.

بنيت مكتبة Dataset فوق SQLAlchemy ويمكن استخدامها ضمن إطار عمل جانغو Django من خلال تعليمات الإدارة inspectdb المبنية داخل جانغو.

Beautiful Soup: مكتبة لاستخراج البيانات من صفحات الويب

تستخرج مكتبة Beautiful Soup المعلومات من صفحات HTML كما أنها تستخدم في تحويل البيانات غير المنظمة أو غير المهيكلة unstructured data في HTML إلى بيانات مهيكلة structured data، كما أنها تعمل بشكل رائع مع بيانات XML صعبة القراءة.

Requests: مكتبة بايثون للعمل مع طلبات HTTP

يمكن القول أن مكتبة Requests هي من أفضل المكتبات المعيارية التي تعمل على محتوى بروتوكول HTTP وتجعل جعل طلبات HTTP أبسط، ففي أي وقت تحتاج لطلب صفحة HTML أو حتى واجهة برمجة تطبيقات API في مشروعك ستقوم مكتبة Requests بتغليف هذا الطلب وتوثيقه بشكل جيد ومفهوم.

Click: مكتبة لكتابة الأوامر الخاصة بسطر الأوامر command-line

تعد مكتبة Click من المكتبات المفضلة عندما تحتاج لكتابة نص برمجي بلغة بايثون ضمن سطر الأوامر command-line، حيث توفر هذه المكتبة واجهة برمجة تطبيقات API بسيطة ومدروسة جيدًا فهي لا تحتوي إلا القليل من النماذج التي نحتاج لتذكرها بالإضافة إلى أنها تمتلك مستندات توثق طريقة عملها بشكل جيد وهذا يسهل عليك عملية البحث عن الميزات المتقدمة ضمن المكتبة.

Python Slugify: مكتبة لتسمية الأشياء ضمن مشروع بايثون

تقدم مكتبة Python Slugify خدمة تسمية الأسماء وفلترتها وتمكنك من تحويل العناوين أو الأوصاف إلى مُعرِّفات مميزة. وهي ضرورية بشكل خاص لمطوري الويب ففي حال كنت تعمل على مشروع ويب يمكنك استخدامها لتحويل روابط URL لصفحات موقعك إلى روابط صديقة لمحركات البحث SEO فهي تجعل عملية التسمية أمرًا سهلًا ومباشرًا.

Pluggy: مكتبة بايثون للعمل مع الإضافات

تعد مكتبة Pluggy من مكتبات بايثون الحديثة نسبيًا ولكنها من أفضل وأسهل الطرق لإضافة الإضافات أو الملحقات plugins إلى تطبيقك الحالي من أجل تعديل جوانب معينة منه أو إضافة ميزات جديدة له، وفي حال تعاملت سابقًا مع إطار اختبار pytest في بايثون فإنك بالتأكيد استخدمت مكتبة Pluggy من دون أن تعرف.

Datasette: مكتبة بايثون لتحويل ملفات CSV إلى API

تعتبر مكتبة Datasette من مكتبات بايثون الرائعة وسهلة الاستخدام لتحويل ملفات CSV إلى تطبيقات REST JSON كاملة المميزات ولكنها تكون تطبيقات قراءة فقط وتمتلك هذه المكتبة الكثير من الميزات المهمة بما في ذلك المخططات والخرائط التفاعلية، وهي سهلة التطبيق ضمن البرامج باستخدام حاوية container أو مضيف ثالث في الويب.

Envparse: مكتبة للتعامل مع متغيرات البيئة في بايثون

في حال كنت تحتاج إلى تفسير متغيرات البيئة environment variables مباشرة لأنك لا تريد حفظ مفاتيح API أو أي معلومات أخرى هامة عن قاعدة البيانات ضمن الشيفرات البرمجية للتطبيق source code، عندها تحتاج إلى استخدام مكتبة Envparse التي تعد واحدة من أفضل مكتبات بايثون التي تعالج متغيرات البيئة وملفات ENV وأنماط المتغيرات، وتساعدك كذلك في إجراء المعالجات المسبقة Preprocessors واللاحقة Postprocessors لهذا المتغيرات عند الضرورة.

Pillow: مكتبة بايثون قوية لعرض ومعالجة الصور

توفر مكتبة Pillow ميزات رائعة للتعامل مع الصور في بايثون فإذا كنت تحتاج إلى معالجة وفتح وحفظ ملفات الصور في مشروعك أنصحك بتجربة هذه المكتبة التي تدعم تنسيقات مختلفة للصور كما تدعم الكثير من التعديلات والفلاتر على الصور مثل تغيير حجم الصورة وتدويرها وتعديل الألوان وتحسين تباينها.

Tkinter: مكتبة بايثون قياسية لبناء الواجهات الرسومية

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

كانت هذه بعض من مكتبات بايثون وهناك بالطبع العديد من المكتبات الغنية بالميزات لكننا سنكتفي بهذه المكتبات العشر ونترك لك حرية اكتشاف العديد منها على متجر مكتبات بايثون الرسمي PyPI.

نصائح لاختيار مكتبات بايثون الأنسب لمشروعك

كما ذكرنا سابقًا يمكن أن تجد العديد من المكتبات التي تخدم غرضك عندما تعمل على مشروع برمجي معين وتتساءل أي مكتبة علي أن اختار؟ إليك يلي بعض الأمور الهامة التي عليك مراعاتها عند اختيار مكتبة ما:

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

الخلاصة

سلطنا الضوء في مقال اليوم على أهم 10 مكتبات مفيدة في بايثون والتي تعتبر بمثابة كنز لأي مبرمج والتي تسرع عمله بشكل كبير وتبسط عملية كتابة الأكواد وإنجاز الوظائف المطلوبة في المشاريع المختلفة.

هل تستخدم أيًا مكتبات بايثون التي استعرضناها في الأعلى أو غيرها؟ شاركنا باسم هذه المكتبة وعرفنا على أبرز الفوائد التي جنيتها من استخدامك لها في مشاريعك البرمجية؟

ترجمة وبتصرّف للمقال 8‎ great Python libraries for side projects‎‎‎ لصاحبيه Lacey Williams Henschel و Jeff Triplett.

نشر المقال بتاريخ 06/01/2019 وجرى تحديثه.

سنتعرف في مقال اليوم على أهم تطبيقات لغة بايثون Python التي ابتكرها المبرمج الهولندي جيدو فان روسوم في أواخر 1989 وكان هدفه الأساسي من تطويرها هو تطوير لغة برمجة جديدة عامة الأغراض تجمع بين البساطة والقوة وتمكن المطور من تحقيق ما يريد بطريقة ممتعة وبأقل عدد من الشيفرات البرمجية وهو ما لم يكن متوفرًا في أي من لغات البرمجة المعروفة آنذاك!

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

ما هي لغة بايثون Python؟

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

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

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

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

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

دورة تطوير التطبيقات باستخدام لغة Python

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

اشترك الآن

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

أهم تطبيقات لغة بايثون

تعد لغة بايثون كما ذكرنا لغة عامة ومتنوعة الأغراض وهي تصلح لكافة أنواع التطبيقات، دعنا نتعرف في فقراتنا التالية على أهم تطبيقات لغة بايثون:

1. أتمتة المهام المتكررة
2. الرياضيات والهندسة
3. علم البيانات
4. الذكاء الاصطناعي والتعلم الآلي
5. تطوير مواقع الويب
6. استخراج بيانات الويب
7. برمجة العتاد وإنترنت الأشياء
8. تطوير تطبيقات سطح المكتب
9. تطوير الألعاب
10. معالجة الصور والتصميم الرسومي

وإليك المزيد من التفاصيل حول كل تطبيق من هذه التطبيقات والأسباب التي تجعل من لغة بايثون ملائمة له.

1. أتمتة المهام المتكررة في بايثون

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

لغة بايثون مثالية لأتمتة المهام بالمقارنة مع لغات برمجة أخرى مثل جافا أو C++‎ أو روبي حيث تتميز بايثون ببساطتها وسرعتها كما أنها توفر لك العديد من هياكل البيانات مثل اللوائح Lists والقواميس Dictionaries والمجموعات sets والصفوف tuples …إلخ. وباختيارك لنمط البيانات المناسب، ستتمكن من تخزين البيانات بأفضل طريقة ومعالجتها بكفاءة وتحقيق أفضل أداء لتطبيقاتك وبرامجك الصغيرة التي تؤدي مهامًا بسيطة مؤتمتة.

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

على سبيل المثال تتضمن بايثون مكتبة قياسية مدمجة بها هي smtplib والتي تساعدك بشكل رائع في أتمتة عملية إرسال رسائل البريد الإلكتروني عبر بروتوكول SMTP من داخل برامج وتطبيقات بايثون، ومكتبة Beautiful Soup التي تمكنك من سحب البيانات المخبأة في ملفات HTML أو غيرها من الأنواع واستخراجها بسهولة بالغة.

2. تطبيقات لغة بايثون في الرياضيات والهندسة

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

ومن أشهر مكتبات بايثون في هذا المجال مكتبة SciPy الشهيرة والرهيبة وهي تجميعة من الحزم المخصصة للاستخدام في المجال العملي ومجال الرياضيات والهندسة حتى الحوسبة العلمية.

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

3. تطبيقات بايثون في علم البيانات

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

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

4. الذكاء الاصطناعي والتعلم الآلي

تلعب لغة بايثون دورًا حيويًا في تطبيقات الذكاء الاصطناعي والتعلم الآلي وتطبيقات لغة بايثون كثيرة في هذا المجال لكونها لغة مستقرة وآمنة وتوفر مكتبات احترافية تتضمن أهم خوارزميات التعلم الآلي وتسهل التعامل مع العمليات الحسابية اللازمة لبناء نماذج التعلم الآلي ومن أهم هذه المكتبات نذكر NumPy و Keras و SciPy و pandas …إلخ.

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

دورة الذكاء الاصطناعي

احترف برمجة الذكاء الاصطناعي AI وتحليل البيانات وتعلم كافة المعلومات التي تحتاجها لبناء نماذج ذكاء اصطناعي متخصصة.

اشترك الآن

5. تطوير مواقع الويب من أهم تطبيقات لغة بايثون

يعد تطوير مواقع الويب من أهم تطبيقات لغة بايثون وهي لغة برمجة أساسية تستخدم في برمجة الواجهة الخلفية لأكبر مواقع الويب والتطبيقات في العالم مثل انستغرام وفيسبوك وكورا و Dropbox و Reddit و Netflex …إلخ.

كما توفر بايثون أطر عمل مميزة تسهل عمل مطوري الويب أبرزها فلاسك Flask وجانغو Django وإطار العمل هو ببساطة مجموعة من الأكواد والوحدات والمكتبات البرمجية المجمعة مع بعضها البعض والتي تجعل عملية تطوير الويب آمنة وموثوقة وتبسط عمليات التفاعل مع قاعدة البيانات وإدارة المحتوى وتقلل من وقت تطوير مواقع الويب بشكل كبير.

6. استخراج بيانات الويب

تتميز بايثون بكونها لغة شائعة الاستخدام في مجال استخراج البيانات من مواقع الويب وصفحات الويب Web scraping بسهولة وسرعة وتتيح الاستفادة منها في عدة استخدامات مثل البحث عن قوائم الوظائف ومقارنة الأسعار وغيرها الكثير من المجالات.

فبدلًا من نسخ هذه البيانات ولصقها يدويًا في مستندات جديدة يمكن بسهولة استخدام أدوات مؤتمتة تقوم بنسخ البيانات ولصقها في البيانات جداول بتنسيق CSV أو JSON. ومن أهم مكتبات بايثون التي تساعدك في استخراج بيانات الويب نذكر BeautifulSoup و MechanicalSoup و Scrapy وغيرها.

7. برمجة العتاد وإنترنت الأشياء

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

فإذا كنت مهتمًا ببرمجة العتاد وتطبيقات إنترنت الأشياء IoT يمكنك التفكير في استخدام لغة بايثون كلغة لتطوير البرامج المضمنة في هذه الأجهزة فهي توفر لك سرعة في كتابة التعليمات البرمجية كما توفر عددًا كبير من المكتبات المتوافقة مع كافة الأنظمة.

ولعل أبرز تطبيقات بايثون في مجال إنترنت الأشياء والأنظمة المدمجة شريحة Raspberry Pi التي تثبت بايثون بشكل مدمج وافتراضي فيها وكل ما عليك هو البدء بكتابة أكواد بايثون الخاصة بك لتعمل مباشرة.

كما يمكنك الاعتماد على إصدار مخصص من لغة بايثون للعمل على الأجهزة ذات الموارد المحدودة يسمى MicroPython الذي يتضمن مكتبات قياسية مخصصة للعمل على المتحكمات الدقيقة والذي يستخدم في لوحة تطوير الإلكترونيات المدمجة PyBoard التي توصل بجهاز الحاسوب بسهولة عبر USB والمتوافقة مع أنظمة التشغيل المختلفة ويندوز ولينكس وماك.

8. تطوير تطبيقات سطح المكتب

يعد تطوير تطبيقات واجهة المستخدم الرسومية GUIs التي تعمل على أجهزة سطح المكتب أحد الاستخدامات المميزة والبارزة للغة بايثون لكونها تملك بنية معيارية ومفهومة وقادرة على العمل على مختلف أنظمة التشغيل.

كما أنها تساعد المطورين في إنشاء تطبيقات سطح مكتب بواجهات رسومية بمنتهى السهولة والكفاءة بفضل العديد من مكتباتها وأطر عملها المدمجة المخصصة لتطوير هذا النوع من التطبيقات ومن أبرزها نذكر Tkinter و wxWidgets و PyQt و PyGUI وغيرها.

وإن أردت تعلم المزيد حول بناء واجهات المستخدم الرسومية في بايثون، فارجع إلى السلسلة التالية برمجة الواجهات الرسومية باستخدام Tkinter.

9. تطبيقات لغة بايثون في تطوير الألعاب

توفر لغة بايثون العديد من المكتبات المفيدة في مجال تطوير الألعاب التفاعلية مثل PySoy وهو محرك ألعاب ثلاثي الأبعاد يدعم بايثون، و PyGame وهي مكتبة مفتوحة المصدر تستخدم على نطاق واسع لتطوير الألعاب وتطوير المشاريع التجارية وتتميز بكونها قابلة للاستخدام على شرائح Raspberry Pi.

وقد استخدمت لغة بايثون في تطوير العديد من الألعاب الشهيرة الاحترافية مثل Battlefield 2 و Vega Strike و World of Tanks فإذا كنت تفكر في احتراف تطوير ألعاب الفيديو ففكر في لغة بايثون بدلًا من استخدام C++‎ أو C#‎ أو جافا سكربت أو جافا لأنها ستسهل عليك مهمتك وتوفر عليك الكثير من الوقت.

يمكنك الرجوع إلى سلسلة بناء لعبة نرد بسيطة بلغة بايثون لبدء تعلم استخدام لغة بايثون في مجال برمجة الألعاب.

10. بايثون ومعالجة الصور والتصميم الرسومي

من تطبيقات لغة بايثون الناجحة إضافة لكل ما سبق، مجال معالجة الصور والتصميم الرسومي فهي تستخدم في تطوير مجموعة من البرامج الرائدة في مجال الرسم ثنائي الأبعاد مثل Inkscape و GIMP و Scribus. كما تستخدم لغة بايثون في العديد من تطبيقات الرسم والنمذجة ثلاثية الأبعاد وأبرزها Autodesk 3ds Max و Blender ومايا Maya و Cinema 4D و Panda3D.

ويمكن أن تقدم بايثون الكثير من الفوائد للمتخصصين في تطوير تطبيقات الرسم بمعونة الحاسوب Computer-Aided Design أو ما يعرف اختصارًا CAD وتمكنهم من إنتاج تصاميم ثنائية الأبعاد أو ثلاثية الأبعاد وتمثيلها بسهولة، على سبيل المثال. يعد Fandango من أشهر تطبيقات التصميم بمعونة الحاسوب وهو يعتمد على لغة بايثون في برمجته.

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

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

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

الخلاصة

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

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

اقرأ أيضًا

• المرجع الشامل إلى تعلم لغة بايثون
• أساسيات البرمجة بلغة بايثون
• بيئات التطوير IDE المستخدمة في تطوير تطبيقات بايثون

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

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

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

خرافة أن الدالة يجب أن تتضمن تعليمة قيمة معادة return وحيدة وفي نهايتها

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

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

خرافة أن الدالة يجب أن تتضمن تعليمة try واحدة على الأكثر

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

>>> import os
>>> def deleteWithConfirmation(filename):
...     try:
...         if (input('Delete ' + filename + ', are you sure? Y/N') == 'Y'):
...             os.unlink(filename)
...     except FileNotFoundError:
...         print('That file already did not exist.')
…

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

>>> import os
>>> def handleErrorForDeleteWithConfirmation(filename):
...     try:
...         _deleteWithConfirmation(filename)
...     except FileNotFoundError:
...         print('That file already did not exist.')
...
>>> def _deleteWithConfirmation(filename):
...     if (input('Delete ' + filename + ', are you sure? Y/N') == 'Y'):
...         os.unlink(filename)
…

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

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

دورة تطوير التطبيقات باستخدام لغة Python

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

اشترك الآن

خرافة أن الوسيط المنطقي خيار سيئ

يطلق على الوسطاء من النوع قيم منطقية Boolean الممررة لدى استدعاء الدوال أو التوابع اسم وسطاء الأعلام أو الرايات flag arguments، والراية في البرمجة هي قيمة تشير إلى عملية إعداد أو ضبط وفق النظام الثنائي، كما في السمتين enabled الدالة على التمكين وdisabled الدالة على إلغاء التمكين، إذ غالبًا ما يعبّر عن الراية بقيمة منطقية، وبذلك يمكننا التعبير عن هذه الإعدادات بأنها إما معيّنة True أو ملغاة False.

وقد أتى الاعتقاد المغلوط بأن استخدام وسطاء الرايات لاستدعاء الدوال هو إجراء سيئ، استنادًا على الادعاء القائل بأنه بناءً على قيمة الراية فإن الدالة ستؤدي مهمتين مختلفتين تمامًا، كما في المثال التالي:

def someFunction(flagArgument):
    if flagArgument:
        # Run some code...
    else:
        # Run some completely different code…

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

خرافة أن المتغيرات العامة خيار سيئ

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

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

فعلى سبيل المثال، لنتمعن في الدالة ()calculateSlicesPerGuest (التي تعني حساب عدد قطع الحلوى لكل ضيف) من البرنامج partyPlanner.py (منسق الحفلة) المُفترض، إذ ضمّنا فيه أرقام الأسطر لتقديم فكرة عن حجم البرنامج الكبير:

1504. def calculateSlicesPerGuest(numberOfCakeSlices):
1505.     global numberOfPartyGuests
1506.     return numberOfCakeSlices / numberOfPartyGuests

وبفرض أننا واجهنا لدى تشغيل البرنامج الاستثناء التالي:

Traceback (most recent call last):
  File "partyPlanner.py", line 1898, in <module>
    print(calculateSlicesPerGuest(42))
  File "partyPlanner.py", line 1506, in calculateSlicesPerGuest
    return numberOfCakeSlices / numberOfPartyGuests
ZeroDivisionError: division by zero

يعرض البرنامج خطأ القسمة على صفر، وهو ناتج عن سطر القيمة المعادة return numberOfCakeSlices / numberOfPartyGuests، وبالتالي لا بد من ان قيمة المتغير numberOfPartyGuests تساوي الصفر ما سبب ظهور هذا الخطأ، والسؤال: أين تم إسناد قيمة الصفر لهذا المتغير؟ فهو متغير عام، وبالتالي من الوارد أن يتم هذا الأمر في أي مكان ضمن آلاف الأسطر التي يتكون منها هذا البرنامج، لكننا نعلم من معلومات متتبع الأخطاء أن استدعاء الدالة ()calculateSlicesPerGuest قد تم في السطر رقم 1898 من البرنامج.

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

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

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

خرافة أن التعليقات غير ضرورية

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

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

ولعل الحالة الأكثر شيوعًا هي وجود برامج بتعليقات قليلة أو بدون تعليقات أكثر من تلك المحتوية على تعليقات كثيرة جدًا أو تعليقات مُضللة. وإجمالًا فإن رفضك للتعليقات يشبه تمامًا اختيارك للسباحة عبر المحيط الأطلسي كون السفر بالطائرة عبره آمن "فقط" بنسبة 99.999991 بالمائة.

الخاتمة

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

ولكن ليست كل دلالات الأخطاء فعلية، فبعضها لا يتعدى كونه خرافات، كالنصائح البرمجية التي لم تعد صالحة أو تلك التي أثبتت أنها تعود على المبرمج بنتائج عكسية، كخرافة وجوب استخدام تعليمة return أو كتلة try-except واحدة ضمن بناء الدالة، مع عدم استخدام وسطاء الأعلام أو المتغيرات العامة بالمطلق، ناهيك عن الاعتقاد القائل بأن التعليقات غير ضرورية.

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

ترجمة -وبتصرف- للجزء الثاني من الفصل الخامس Finding Code Smells من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigarti.

اقرأ أيضًا

• المقال السابق: اكتشاف دلالات الأخطاء في شيفرات لغة بايثون
• ثلاثة أخطاء عليك تفاديها عند تعلم البرمجة بلغة بايثون
• التعامل مع رسائل الأخطاء في بايثون

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

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

وبالتأكيد لا تعني "رائحة" الشيفرة وجود مشكلة بالضرورة، وبالنتيجة وكما اعتدنا فالربان هو أنت، والقرار حول التعامل مع هذه الرائحة أو إهمالها هو قرار شخصي يعود إليك.

قبل التعرف على كيفية اكتشاف أخطاء الشيفرات في لغة بايثون، ندعوك للتعرف على الأخطاء البرمجية عامةً أولًا والتعرف على كيفية التعامل معها:

والآن دعونا نتحدث عن دلالات وجود الأخطاء في شيفرات لغة بايثون.

تكرار الشيفرات

إحدى أكثر دلالات الأخطاء (روائح الشيفرات) شيوعًا هي الشيفرات المكررة، وهي بالتعريف أي شيفرة مصدرية مُنشأة باستخدام نسخ ولصق أجزاءً من شيفرة أُخرى ضمن شيفرتك الحالية عدة مرات، فمثلًا يتضمن البرنامج التالي شيفراتٍ مكررة، إذ نلاحظ أنها تسأل المستخدم عن حاله (?How are you feeling) ثلاث مرات:

print('Good morning!')
print('How are you feeling?')
feeling = input()
print('I am happy to hear that you are feeling ' + feeling + '.')
print('Good afternoon!')
print('How are you feeling?')
feeling = input()
print('I am happy to hear that you are feeling ' + feeling + '.')
print('Good evening!')
print('How are you feeling?')
feeling = input()
print('I am happy to hear that you are feeling ' + feeling + '.')

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

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

def askFeeling():
    print('How are you feeling?')
    feeling = input()
    print('I am happy to hear that you are feeling ' + feeling + '.')

print('Good morning!')
askFeeling()
print('Good afternoon!')
askFeeling()
print('Good evening!')
askFeeling()

أما في المثال التالي، فتخلصنا من التكرار عبر حصر الجزء المكرر ضمن حلقة:

for timeOfDay in ['morning', 'afternoon', 'evening']:
    print('Good ' + timeOfDay + '!')
    print('How are you feeling?')
    feeling = input()
    print('I am happy to hear that you are feeling ' + feeling + '.')

كما من الممكن دمج كلا تقنيتي التخلص من التكرار باستخدام دالة وحلقة معًا، بالشكل:

def askFeeling(timeOfDay):
    print('Good ' + timeOfDay + '!')
    print('How are you feeling?')
    feeling = input()
    print('I am happy to hear that you are feeling ' + feeling + '.')

for timeOfDay in ['morning', 'afternoon', 'evening']:
    askFeeling(timeOfDay)

ونلاحظ أن الشيفرة المسؤولة عن عرض رسائل الترحيب "!Good morning/afternoon/evening" أي صباح/ظهر/مساء الخير الناتجة بعض التخلص من التكرار متشابهة ولكنها غير متطابقة، ففي التطوير الثالث لحل المشكلة ثبتنا الأجزاء المتطابقة من الشيفرة لتجنب التكرار، في حين يحل المعامل timeOfDay ومتغير الحلقة timeOfDay محل الأجزاء المتغيرة، وبذلك وبعد التخلص من التكرار عبر إزالة النسخ الزائدة، ما علينا سوى التعديل في مكان واحد متى ما احتجنا ذلك.

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

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

يعد تكرار الشيفرات من دلالات وقوع الأخطاء لأنه يجعل من شيفرتك أصعب للتعديل، ففي حال وجود العديد من التكرارات في برنامجك، يكون الحل بحصر الجزء المكرر ضمن حلقة أو دالة ليظهر لمرة واحدة فقط.

دورة تطوير التطبيقات باستخدام لغة Python

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

اشترك الآن

الأرقام السحرية

ليس عجبًا إن قلنا أنّ البرمجة تتضمن استخدام الأرقام، إلا أن بعض الأرقام التي تظهر ضمن شيفرتك المصدرية قد تكون مصدر إرباك لمبرمج آخر يقرؤها (أو حتى لك أنت بعد مرور عدة أسابيع على كتابتك لها) وهي ما ندعوه بالأرقام السحرية magic numbers أي تلك الأرقام في الشيفرة التي قد تبدو عشوائية أو عديمة السياق والمعنى، فعلى سبيل المثال، لاحظ الرقم 604800 في السطر البرمجي التالي:

expiration = time.time() + 604800

تعيد الدالة ()time.time رقمًا صحيحًا يمثل الوقت الحالي، ويمكننا فهم أن المتغير expiration والذي يعني وقت الانتهاء يمثل لحظة زمنية ما بعد مرور زمن قدره 604800 ثانية، إلا أن هذا الرقم هو مصدر الإرباك الأساسي، وأول ما سيتبادر إلى الذهن "ما مغزى تاريخ انتهاء الصلاحية هذا؟"، وفي الواقع، تعليق بسيط قد يحل المشكلة، بالشكل:

expiration = time.time() + 604800  # Expire in one week.

يمكن عد التعليق السابق حلًا جيدًا، إلا أن الأفضل هو استبدال الأرقام السحرية بثوابت، وتعرّف الثوابت بأنها متغيرات تُكتب بأحرف كبيرة دلالةً على أن قيمها يجب ألا تتغير عن القيمة البدائية المُسندة لها، وعادةً ما نصرح عن الثوابت في قسم التصريحات العامة، أي في بداية ملف الشيفرة، كما في الشكل:

# Set up constants for different time amounts:
SECONDS_PER_MINUTE = 60
SECONDS_PER_HOUR   = 60 * SECONDS_PER_MINUTE
SECONDS_PER_DAY    = 24 * SECONDS_PER_HOUR
SECONDS_PER_WEEK   = 7  * SECONDS_PER_DAY

--snip--

expiration = time.time() + SECONDS_PER_WEEK  # Expire in one week.

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

NUM_CARDS_IN_DECK = 52
NUM_WEEKS_IN_YEAR = 52

print('This deck contains', NUM_CARDS_IN_DECK, 'cards.')
print('The 2-year contract lasts for', 2 * NUM_WEEKS_IN_YEAR, 'weeks.')

ولدى تشغيل الشيفرة السابقة، سيبدو الخرج بالشكل:

This deck contains 52 cards.
The 2-year contract lasts for 104 weeks.

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

NUM_CARDS_IN_DECK = 53
NUM_WEEKS_IN_YEAR = 52

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

while True:
    print('Set solar panel direction:')
    direction = input().lower()
    if direction in ('north', 'south', 'east', 'west'):
        break

print('Solar panel heading set to:', direction)
1 if direction == 'nrth':
    print('Warning: Facing north is inefficient for this panel.')

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

# Set up constants for each cardinal direction:
NORTH = 'north'
SOUTH = 'south'
EAST = 'east'
WEST = 'west'

while True:
    print('Set solar panel direction:')
    direction = input().lower()
    if direction in (NORTH, SOUTH, EAST, WEST):
        break

print('Solar panel heading set to:', direction)
1 if direction == NRTH:
    print('Warning: Facing north is inefficient for this panel.')

إن السطر رقم 1 من الشيفرة السابقة مع الخطأ الطباعي في كلمة NRTH سيثير لدى تشغيله استثناء NameError جاعلًا مصدر الخطأ جليًا على الفور:

Set solar panel direction:
west
Solar panel heading set to: west
Traceback (most recent call last):
  File "panelset.py", line 14, in <module>
    if direction == NRTH:
NameError: name 'NRTH' is not defined

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

إلغاء الشيفرات بتحويلها إلى تعليقات ومفهوم الشيفرة الميتة

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

doSomething()
#doAnotherThing()
doSomeImportantTask()
doAnotherThing()

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

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

>>> import random
>>> def coinFlip():
...     if random.randint(0, 1):
...         return 'Heads!'
...     else:
...         return 'Tails!'
...     return 'The coin landed on its edge!'
...
>>> print(coinFlip())
Tails!

في الشيفرة السابقة، يمكن عد القيمة المعادة "!The coin landed on its edge" كشيفرة ميتة، إذ أن الشيفرة ستعيد قيم لحالات تحقق وعدم تحقق الشرط قبل أن يتمكن التنفيذ من بلوغ هذا السطر. قد تسبب الشيفرات الميتة الضياع لأن المبرمج القارئ لهذه الشيفرة سيعتبرها كجزء فعال من البرنامج في حين أن تأثيرها على الخرج لا يتعدى تأثير التعليقات عليه.

يُستثنى من دلالات الأخطاء الشيفرة النائب Stubs، وهي عبارة عن مواضع مؤقتة للشيفرات المستقبلية، كالدوال والأصناف التي لم يتم تطبيقها بعد، فبدلًا من استخدام شيفرات حقيقية، يتضمن النائب عبارة مرور pass فقط، والتي لا تقوم بأي دور فعليًا (تسمى أيضًا العبارة عديمة الدور no operation أو no-op)، فالتعليمة pass موجودة لتستخدمها في الأماكن المفروض استخدام تعليمات فيها، في حين أنك لا ترغب بإضافتها الآن، لتنشئ بدلًا من ذلك شيفرة نائب مؤقتة، كما في المثال:

>>> def exampleFunction():
...     pass
…

إن استدعاء الدالة السابقة لن يقوم بأي وظيفة، سوى الإشارة إلى أنه ستتم إضافة شيفرات له لاحقًا.

وكبديل عن استدعاء تابع لا يقوم بأي دور، يمكنك جعله يعرض بالنيابة (عن دوره المتوقع المستقبلي) رسالة مفادها أن هذه الدالة ليست جاهزة للاستدعاء بعد باستخدام التعليمة raise NotImplementedError، بالشكل:

>>> def exampleFunction():
...     raise NotImplementedError
...
>>> exampleFunction()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in exampleFunction
NotImplementedError

ظهور الرسالة NotImplementedError سيمثل تنبيه لحالة استدعاء البرنامج لدالة أو تابع نائب عن طريق الصدفة.

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

التنقيح باستخدام دالة الطباعة

التنقيح باستخدام دالة الطباعة هو الإجراء المتمثل باستدعاء الدالة ()print مؤقتًا ضمن البرنامج بغية عرض قيم المتغيرات قبل تشغيل البرنامج، وعادةً ما تمر هذه العملية بالخطوات التالية:

1. ملاحظة وجود خطأ في البرنامج.
2. إضافة بعض الاستدعاءات للدالة ()print لبعض المتغيرات في محاولة معرفة ما تحتويه.
3. إعادة تشغيل البرنامج.
4. إضافة المزيد من الاستدعاءات للدالة ()print لأن الاستدعاءات السابقة لم تعرض ما يكفي من معلومات.
5. إعادة تشغيل البرنامج.
6. تكرار الخطوتين السابقتين عدة مرات إلى حين اكتشاف موضع الخطأ.
7. إعادة تشغيل البرنامج.
8. إدراك أنك قد نسيت حذف بعضًا من استدعاءات الدالة ()print، فتحذف ما تبقى منها.

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

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

import logging
logging.basicConfig(filename='log_filename.txt', level=logging.DEBUG, format='%(asctime)s - %(levelname)s - %(message)s')
logging.debug('This is a log message.')

فبعد استيراد وحدة السجل logging وضبط إعداداتها الرئيسية، يصبح من الممكن استدعاء التابع ()logging.debug لكتابة معلومات السجل ضمن مستند نصي، في حين أن الدالة ()print تعرض معلوماتها على شاشة الخرج.

وعلى النقيض من التنقيح باستخدام دالة الطباعة، فإن استدعاء الدالة ()logging.debug يجعل من الواضح أي أجزاء من الخرج هي معلومات تنقيحية وأيها خرج البرنامج الفعلي.

المتغيرات ذات اللاحقات الرقمية

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

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

لنأخذ مثالًا آخر، بفرض أنه لدينا تابع يتعامل مع إحداثيات بداية ونهاية، فقد تسمي المعاملات حينها x1 و y1 و x2 و y2 على التوالي، إلا أن هذه الأسماء لا تقدّم معلوماتٍ كما لو أسميتها start_x و start_y و end_x و end_y، ناهيك عن كون الاسمين start_x و start_y أكثر ترابطًا من x1 وy1 كتعبير عن تمثيلهما لإحداثيات نقطة البداية start.

أما في حال تجاوز عدد المتغيرات ذات اللواحق الرقمية لاثنين، فعندها من المستحسن استخدام بنية معطيات كالقائمة list أو المجموعة set لتخزين هذه البيانات ضمن هيكلية، فمثلًا لو كان لدينا مجموعة من المتغيرات بالأسماء pet1Name و pet1Name وpet1Name وهكذا فمن الممكن تخزين قيمها ضمن قائمة واحدة باسم petNames.

ومن الجدير بالملاحظة أن اللاحقة الرقمية لا تعد دلالة على الخطأ في أي متغير منتهٍ برقم، فمثلًا يعتبر الاسم enableIPV6 مثاليًا لمتغير، لأن الرقم 6 هو جزء من اسم البروتوكول "IPV6" ولا يمثّل لاحقة رقمية. أما في حال كنت ممن يستخدمون اللواحق الرقمية لتسمية سلسلة من المتغيرات، فمن المفضّل بدلًا من ذلك تخزين قيمها ضمن بنية معطيات ما، كقائمة أو قاموس أو غيرها.

الأصناف التي يجب أن تكون مجرد دوال أو توابع

اعتاد المبرمجون ممن يستخدمون لغات برمجة مثل جافا Java على إنشاء الأصناف بغية تنظيم شيفرات برامجهم، لنأخذ على سبيل المثال الصنف التالي المسمى Dice (بمعنى حجر النرد) والمتضمّن للتابع ()roll (والمقصود به رمي حجر النرد):

>>> import random
>>> class Dice:
...     def __init__(self, sides=6):
...         self.sides = sides
...     def roll(self):
...         return random.randint(1, self.sides)
...
>>> d = Dice()
>>> print('You rolled a', d.roll())
You rolled a 1

فقد تبدو الشيفرة السابقة بأنها شيفرة عالية التنظيم، ولكن ماذا لو فكرنا باحتياجاتنا الفعلية من هذه الشيفرة؟ أليست مجرد الحصول على رقم عشوائي محصور بين 1 و 6، وبالتالي من الممكن استبدال كامل الصنف السابق باستدعاء بسيط لتابع بالشكل:

>>> print('You rolled a', random.randint(1, 6))
You rolled a 6

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

إذ أننا نستخدم في بايثون الوحدات لتجميع الدوال مع بعضها البعض بدلًا من استخدام الأصناف، ذلك لأن الأصناف بحد ذاتها يجب أن تتواجد ضمن وحدات بطبيعة الحال، ما يجعل تضمين الدوال في أصناف مجرد إضافة غير ضرورية لمستوى تنظيمي جديد لشيفرتك، وتناقش الفصول من 15 حتى 17 في كتابنا هذا مبادئ التصميم كائني التوجّه تفصيليًا، كما تحدث Jack Diederich’s في خطابه ضمن مؤتمر بايثون لعام 2012 تحت عنوان Stop Writing Classes "كفوا عن كتابة الأصناف" حول العديد من الطرق التي يستخدمها المبرمجون، مضيفين بذلك تعقيدًا غير ضروريًا لشيفراتهم المكتوبة في بايثون.

بنى اشتمالات القوائم المتداخلة

يعد اشتمال القوائم List comprehensions طريقة مختصرة لإنشاء قائمة ذات قيم معقدة، فمثلًا لإنشاء قائمة سلاسل محرفية متضمنةً الأرقام من 0 حتى 100 باستثناء مضاعفات العدد 5، فعادةً ما ستستخدم حلقة for بالشكل:

>>> spam = []
>>> for number in range(100):
...     if number % 5 != 0:
...         spam.append(str(number))
...
>>> spam
['1', '2', '3', '4', '6', '7', '8', '9', '11', '12', '13', '14', '16', '17',
--snip--
'86', '87', '88', '89', '91', '92', '93', '94', '96', '97', '98', '99']

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

>>> spam = [str(number) for number in range(100) if number % 5 != 0]
>>> spam
['1', '2', '3', '4', '6', '7', '8', '9', '11', '12', '13', '14', '16', '17',
--snip--
'86', '87', '88', '89', '91', '92', '93', '94', '96', '97', '98', '99']

كما تمتلك لغة بايثون صيغًا لاشتمال كل من القواميس والمجموعات:

1 >>> spam = {str(number) for number in range(100) if number % 5 != 0}
>>> spam
{'39', '31', '96', '76', '91', '11', '71', '24', '2', '1', '22', '14', '62',
--snip--
'4', '57', '49', '51', '9', '63', '78', '93', '6', '86', '92', '64', '37'}
2 >>> spam = {str(number): number for number in range(100) if number % 5 != 0}
>>> spam
{'1': 1, '2': 2, '3': 3, '4': 4, '6': 6, '7': 7, '8': 8, '9': 9, '11': 11,
--snip--
'92': 92, '93': 93, '94': 94, '96': 96, '97': 97, '98': 98, '99': 99}

أنشأنا في السطر ذو الرقم 1 بنية اشتمال مجموعة باستخدام الأقواس المعقوصة بدلًا من المعقوفة لتُنتج مجموعة من القيم، أما في السطر ذو الرقم 2 فأنشأنا بنية اشتمال قاموس باستخدام محرف النقطتين الرأسيتين لفصل المفتاح عن القيم ضمن الاشتمال.

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

>>> nestedIntList = [[0, 1, 2, 3], [4], [5, 6], [7, 8, 9]]
>>> nestedStrList = [[str(i) for i in sublist] for sublist in nestedIntList]
>>> nestedStrList
[['0', '1', '2', '3'], ['4'], ['5', '6'], ['7', '8', '9']]

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

>>> nestedIntList = [[0, 1, 2, 3], [4], [5, 6], [7, 8, 9]]
>>> nestedStrList = []
>>> for sublist in nestedIntList:
...     nestedStrList.append([str(i) for i in sublist])
...
>>> nestedStrList
[['0', '1', '2', '3'], ['4'], ['5', '6'], ['7', '8', '9']]

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

>>> nestedList = [[0, 1, 2, 3], [4], [5, 6], [7, 8, 9]]
>>> flatList = [num for sublist in nestedList for num in sublist]
>>> flatList
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

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

>>> nestedList = [[0, 1, 2, 3], [4], [5, 6], [7, 8, 9]]
>>> flatList = []
>>> for sublist in nestedList:
...     for num in sublist:
...         flatList.append(num)
...
>>> flatList
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

إذًا تعد الاشتمالات كاختصارات قادرة على اختصار الشيفرات شريطة عدم المبالغة والذهاب نحو خيار الاشتمالات المتداخلة صعبة القراءة والفهم.

كتل الاستثناءات except الفارغة ورسائل الأخطاء الضعيفة

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

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

>>> try:
...     num = input('Enter a number: ')
...     num = int(num)
... except ValueError:
...     pass
...
Enter a number: forty two
>>> num
'forty two'

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

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

كما أن التعامل مع الاستثناءات برسائل أخطاء ضعيفة هو أيضًا من دلالات الوقوع في الأخطاء، كما في المثال التالي:

>>> try:
...     num = input('Enter a number: ')
...     num = int(num)
... except ValueError:
...     print('An incorrect value was passed to int()')
...
Enter a number: forty two
An incorrect value was passed to int()

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

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

الخاتمة

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

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

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

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

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

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

ترجمة -وبتصرف- للجزء الأول من الفصل الخامس Finding Code Smells من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigarti.

اقرأ أيضًا

• المقال السابق: اختيار أسماء برمجية مفهومة في بايثون
• حل المشكلات وأهميتها في احتراف البرمجة

"المسألتان الأصعب في علم الحاسوب هما ثلاثة! اختيار الأسماء وحذف أو استبدال محتويات الذاكرة المخبئية cache invalidation وتجنب أخطاء التكرار المنطقية off-by-one" هي إحدى أقدم الدعابات البرمجية، المنسوبة إلى ليون بامبريك والمستوحاة من اقتباس لفيل كارلتون، إلا أنها تشير إلى حقيقة جوهرية، مفادها أن ابتكار أسماء جيدة للمتغيرات والدوال والأصناف وغيرها مما يسمى إجمالًا بالمعرفات ليست بالمهمة السهلة.

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

ما لم تكن تكتب شيفرة تجريبية لا تنوي الاحتفاظ بها بعد اختبارها وتشغيلها لمرة واحدة، يجب عليك التفكير في اختيار الأسماء الجيدة في برنامجك. فإن استخدمت أسماء بسيطة من قبيل a وb وc للمتغيرات، فستبذل مستقبلًا جهدًا إضافيًا لتذكّر ما كان الغرض من استخدام كل من هذه المتغيرات.

ومما لا شك فيه أن اختيار الأسماء هو قرار شخصي أنت المسؤول عنه، إذ لا يمكن لأداة تنسيق آلي من قبيل المنسّق Black، الذي أتينا على شرحه في المقال السابق، أن يختار الأسماء للمتغيرات الخاصة بك.

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

المتغيرات ذات الأسماء المؤقتة البديلة

عادة ما نستخدم المتغيرات ذات الأسماء المؤقتة البديلة Metasyntactic في المواد التعليمية أو في أمثلة الشيفرات البرمجية كعنصر نائب، إذ نحتاج إلى مجرد اسم فريد للمتغير. فغالبًا ما تسمى المتغيرات في أمثلة بايثون بأسماء عشوائية من قبيل spam و eggs حين يكون اختيار الاسم غير مهم، ولهذا السبب نستخدم في كتابنا هذا النوع من الأسماء في أمثلة الشيفرات التي لا يكون مطلوبًا منك استخدامها في برامجك الفعلية، إذ اقتبسنا هذه الأسماء من مشهد تمثيلي لمجموعة مونتي بايثون البريطانية للكوميديا السيريالية بعنوان البريد العشوائي "Spam (Monty Python sketch)‎".

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

التنسيق المتعلق بحالة الحروف

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

وإحدى هذه الطرق هي طريقة الثعبان مع الحروف الصغيرة snake_case، وفيها نفصل بين الكلمات في اسم المعرف الواحد بشرطة سفلية، والتي تبدو كثعبان متمدد بين الكلمات، وتملي هذه الطريقة على استخدام الحروف الصغيرة بالكامل، عدا في حالات التصريح عن الثوابت، إذ تُستخدم حينها طريقة الثعبان مع أحرف كبيرة UPPER_SNAKE_CASE في الغالب.

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

وطريقة باسكال PascalCase، والتي تُنسب تسميتها إلى استخدامها في لغة البرمجة باسكال، فهي مشابهة لطريقة camelCase إلا أن أول كلمة تبدأ أيضا بحرف كبير.

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

اصطلاحات التسمية وفق دليل بايثون الإرشادي PEP 8

تقدم وثيقة PEP 8 بعضًا من التوصيات حيال اصطلاحات التسميات في بايثون، ومنها:

• كل الحروف يجب أن تكون وفق نظام الآسكي ASCII، أي حروف إنجليزية بحالتيها الكبيرة والصغيرة دون إشارات الحركات.
• يجب تسمية الوحدات بأسماء قصيرة وبحروف صغيرة.
• يجب تسمية الأصناف وفق طريقة PascalCase.
• يجب تسمية الثوابت وفق طريقة UPPER_SNAKE_CASE.
• يجب تسمية الدوال والتوابع والمتغيرات وفق طريقة snake_case بحروف صغيرة.
• يجب تسمية أول وسيط في التوابع باستخدام حروف صغيرة.
• يجب تسمية أول وسيط في تابع الصنف بالاسم cls وبحروف صغيرة.
• يجب أن تبدأ السمات الخاصة في الصنف دائما بعلامة الشرطة السفلية.
• يجب ألا تبدأ السمات العامة في الصنف بعلامة الشرطة السفلية أبدًا.

يمكنك التغاضي عن هذه القواعد وفق الضرورات، فمثلًا وعلى الرغم من كون اللغة الإنجليزية هي المألوفة برمجيًا، إلا أنك تستطيع استخدام محارف أي لغة أخرى، فمثلًا 'コンピューター = 'laptop هي شيفرة برمجية صالحة نحويًا في بايثون، وكذلك يمكن استخدام اللغة العربية كما يلي:

コンピューター = 'laptop'
المنتج = 'laptop'

أما عن الأسماء في هذه السلسلة هذا فقد اختيرت وفقًا للدليل PEP 8، إذ اعتمدنا طريقة camelCase تحديدًا وليس طريقة snake_case. ويتضمّن PEP 8 تنويهًا مفاده أن المبرمج ليس مضطرًا لاتباع هذه الاصطلاحات بصرامة، فالعامل الأهم للمقروئية هو وحدة الطريقة المستخدمة في التسمية في كامل البرنامج وليس الطريقة بحد ذاتها.

كما يمكنك الاطلاع على قسم "اصطلاحات التسمية" في دليل PEP 8 كاملًا بزيارة python.org.

اختيار الطول المناسب للاسم

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

أسماء قصيرة جدا

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

• الأسماء المكونة من حرف أو اثنين، كالاسم g الذي يشير عادةً لكلمة تبدأ بهذا الحرف، وما أكثرها! فرغم كون الاختصارات والأسماء المكونة من حرف واحد أو حرفين سهلة للكتابة بالنسبة لك، إلا أنها صعبة القراءة والفهم لغيرك.
• الاختصارات، فاختصار مثل mon يشير إلى عدد كبير من الكلمات مثل monitor و month و monster وغيرها الكثير.
• الأسماء المكونة من كلمة واحدة قد تكون غامضة أيضًا، كالاسم start والذي يعني "بداية"، ولكن بداية ماذا؟ إذ يفتقد هذا النوع من الأسماء إلى السياق الواضح عند قراءة الشيفرة من قبل غير كاتبها.

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

وفيما يلي بعض الاستثناءات التي يكون من المناسب فيها استخدام الأسماء القصيرة، فمثلًا من الشائع استخدام i كاسم لمتغير حلقة for التكرارية التي تمر على نطاق من الأعداد أو مؤشرات قائمة ما، كما من الشائع استخدام كلًا من الحرفين j و k (كونهما الحرفان التاليان للحرف i أبجديًا) في حال استخدامك لعدّة حلقات متداخلة، كما في المثال:

>>> for i in range(10):
...     for j in range(3):
...         print(i, j)
...
0 0
0 1
0 2
1 0
--snip--

كما أنّ استخدام الحرفين x و y في تمثيل الإحداثيات الديكارتية يمثّل استثناءً آخر. وفيما عدا ذلك لا أنصح باستخدام أسماء بحرفٍ واحد على الإطلاق، فرغم كونها جذابة للاستخدام، كأن تستخدم الاسم w للدلالة على العرض width والاسم h للدلالة على الارتفاع height والاسم n للدلالة على عدد ما number، إلا أنها لن تكون واضحة ومفهومة للآخرين.

لا تختصر حروفا من شيفرتك المصدرية

كانت طريقة اختصار الأحرف من الكلمات شائعة الاستخدام في الفترة ما قبل تسعينيات القرن الماضي في لغة البرمجة C، كأن نستخدم الاسم memcpy للدلالة على نسخة ذاكرة memory copy أو strcmp للدلالة على المقارنة بين السلاسل النصية string compare، إلا أن هذه الطريقة تعد نمطًا غير مقروء من أنماط التسمية ويجب عدم استخدامها في أيامنا، فإن كان من الصعب نطق هذا الاسم، فما بالك بفهمه؟ لن يكون سهلًا بالطبع.

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

أسماء طويلة جدا

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

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

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

استخدام البادئات في الأسماء

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

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

ولكن ومن ناحية أخرى، فإنّه من المفيد استخدام بادئات من قبل is بمعنى "أهو؟ أو هو يكون" و has بمعنى "لديه أو ذي" ضمن أسماء المتغيرات المُتضمنة لقيم منطقية أي من النوع Boolean، أو ضمن أسماء الدوال والتوابع التي تعيد قيمًا منطقية، لما لذلك من دور في زيادة المقروئية، فمثلًا في المثال التالي، لاحظ استخدام متغير باسم is_vehicle بمعنى "فإنه مركبة" وتابع باسم ()has_key بمعنى "يملك المفتاح":

if item_under_repair.has_key('tires'): 
  is_vehicle = True

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

وبشكل مشابه، فإن إضافة وحدات القياس لأسماء المتحولات قد يحسّن من مقروئية الشيفرات مضيفًا معلومات مفيدة، فمثلًا إن كان لدينا متغير يتضمن قيمة الكتلة محتويًا على بيانات من نوع الفاصلة العائمة، فقد يعتري القارئ بعض الغموض حول وحدة القياس المعتمدة، أهي الكيلوغرام أم الباوند أم الطن؟ وبما أن وحدات القياس هذه ليست من أنماط البيانات، فإن إضافة أي من kg أو lbs أو tons كبادئة أو لاحقة لا يعد اتباعًا للطريقة الهنغارية، ففي حال لم نكن نستخدم نمط بيانات خاص بالكتلة يتضمن معلومات حول وحدة قياسها، فمن المفضّل تسمية المتغير باسم من قبيل weight_kg.

فمثلًا، فُقد مسبار المريخ الفضائي الآلي المداري عام 1999 بسبب اختلاف وحدات قياس الحسابات الناتجة عن البرمجيات التي أنتجتها شركة Lockheed Martin والتي استخدمت وحدات القياس البريطانية، وتلك الناتجة عن أنظمة وكالة الفضاء الدولية (ناسا) والتي استخدمت وحدات القياس المترية، ما أدى كنتيجة إلى تحديد المسار بشكل خاطئ، وخسائر قدرت بنحو 125 مليون دولار أمريكي.

اللاحقات الرقمية المتتالية

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

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

كذلك الأمر بالنسبة للدوال ذات الأسماء من قبيل (makePayment1(amount و(makePayment2(amount وهكذا، والتي يجب استبدالها بدالة وحيدة تقبل وسيطًا من النوع عدد صحيح، ليصبح استدعاؤها بالشكل: (makePayment(1, amount و(makePayment(2, amount وهكذ.

أما في حال كون تلك الدوال ذات وظائف مختلفة، بما يفرض استخدام دوال مستقلة، فمن الحري بنا في هذه الحالة استبدال الرقم في الاسم بما يوضح دور الدالة، مثل:

• (makeLowPriorityPayment(amount لتدل على المدفوعات ذات الأولوية الأقل
• (makeHighPriorityPayment(amount للدلالة على المدفوعات ذات الأولوية الأعلى
• (make1stQuarterPayment(amount للدلالة على مدفوعات الربع الأول من السنة
• (make2ndQuarterPayment(amount للدلالة على مدفوعات الربع الثاني من السنة

أما في حال وجود سبب وجيه لاستخدام أسماء بلاحقات رقمية متتالية فلا بأس في ذلك، وإن كان ذلك فقط من باب الاستسهال فعليك العمل على تغييرها.

استخدم أسماء يسهل البحث عنها

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

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

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

تجنب النكات والتورية والإشارات الثقافية

خلال عملي -يقول المؤلف- في إحدى شركات تطوير البرمجيات، صادفتني دالة باسم ()gooseDownload، ولم يكن لدي أي تصور حول ما تعنيه، "تنزيل الإوزة!" إذ لم يكن للمنتج الذي نعمل عليه أي صلة بالطيور أو تحميل الطيور، ولدى إيجادي لشريك العمل الأقدم الذي كتب هذه الدالة، شرح لي بأن كلمة إوزة هنا يُقصد بها فعل وليس اسم، كما في الجملة goose the engine (بمعنى تهيئة محرك السيارة بإعطاءه دفعة كبيرة من الوقود مُصدرًا صوتًا يشبه صوت الإوزة).

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

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

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

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

لا تستخدم الأسماء المحجوزة

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

>>> list(range(5))
[0, 1, 2, 3, 4]
1 >>> list = ['cat', 'dog', 'moose']
2 >>> list(range(5))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'list' object is not callable```

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

ولمعرفة فيما إذا كان اسمًا معينًا محجوزًا في بايثون أم لا، يكفي كتابته ضمن الصدفة التفاعلية أو أن نحاول استيراده، فلو حصلنا على أحد الخطأين NameError أو ModuleNotFoundError، فهذا يعني أن الاسم غير محجوز، فمثلًا الأسماء open و test محجوزة في بايثون، في حين spam و eggs ليست كذلك:

>>> open 
<built-in function open >
>>> import test
>>> spam 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'spam' is not defined
>>> import eggs 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'eggs'

ومن أشهر الكلمات المحجوزة التي يستخدمها المبرمجون خطأً هي:

all any data email file format hash id input list min max object open random set str sum test type

فلا تستخدم هذه الأسماء للمعرفات بأنواعها.

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

>>> # Run this code with a file named pyperclip.py in the current folder.
>>> import pyperclip # This imports your pyperclip.py, not the real one.
>>> pyperclip.copy('hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'pyperclip' has no attribute 'copy'

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

أسوأ أسماء المتغيرات على الإطلاق

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

فلطفًا لو احتجت لمتغير يعبّر عن التباين الاحصائي لبيانات درجة الحرارة، اختر الاسم temperatureVariance غير مباليًا بدلالات الثلاثي الشهير tempVarData.

الخاتمة

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

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

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

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

ترجمة -وبتصرف- للفصل الرابع Code Formatting With Black من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigarti.

اقرأ أيضًا

• مدخل إلى لغة بايثون البرمجية
• أساسيات البرمجة بلغة بايثون
• التعامل مع القوائم والسلاسل النصية في لغة بايثون
• اكتشاف دلالات الأخطاء في شيفرات لغة بايثون

تُعَدّ البرمجة كائنية التوجه Object Oriented Programming -أو OOP اختصارًا- نمطًا من أنماط البرمجة التي يُكتَب فيها البرنامج على صورة كائنات تحتوي على خاصيات ومهام -أي دوال- فيمكن مثلًا التفكير في السيارة على أساس كائن، إذ يكون لون السيارة ولون إطاراتها واسم الشركة المصنعة للسيارة خاصيات لها؛ أما مهمة حركة السيارة ومهمة إنقاص سرعة السيارة ومهمة زيادة سرعة السيارة، فهي دوال.

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

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

مفهوم الصنف class والكائن object

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

وبناءً على ذلك فإنَ الأصناف Classes لا تؤدي حقًا أيّ مهمة، فهي في الواقع نوع جديد من هيكلة البيانات الذي يعرِّفه المبرمج لتحديد الخاصيات والدوال الموجودة في كائنات تلك الأصناف، لكنها بدورها لا تحمل قيمة لأي خاصية ولا تنفِّذ أيّ دالة، فهي أشبه بمخطط فقط أو فكرة مجردة.

سيحمل الصنف إنسان في مثالنا السابق خاصيات مثل الاسم والعمر ولون البشرة ولون الشعر ولكنه لا يحمل قيمةّ للاسم مثل أحمد أو محمد، ولا يحمل قيمة للعمر مثل 14 أو 40 عامًا، ولا غيرها من الخاصيات وإنما يعرِّف الصنف تلك الخاصيات فقط لكي تُسنَد قيم لتلك الخاصيات عند إنشاء كائن من ذلك الصنف، وكذلك الأمر في الدوال، إذ يحمل الصنف نفسه شيفرة تلك الدوال، لكنه ينفِّذها بذاته إلا عند استدعاء تلك الدوال لتنفيذها من قِبَل كائنات الصنف.

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

إنشاء صنف في بايثون

لإنشاء صنف جديد في بايثون، نستطيع استخدام الكلمة المفتاحية class متبوعةً باسم الصنف الذي من المفضَّل أن يبدأ بحرف كبير وليس شرطًا، ثم نبدأ كتلةً تحتوي على الخاصيات والدوال بالشكل التالي:

class Human:
    pass

عرَّفنا في المثال السابق صنفًا جديدًا باسم Human، ولا تحمل كتلته أيّ تعليمات حاليًا لذلك أضفنا الكلمة المفتاحية pass التي ذكرناها سابقًا بأنها تُستَعمل في حالة عدم وجود أيّ تعليمات في كتلة الشيفرة في حلقات التكرار وقواعد اتخاذ القرارات، وكذلك تستخدَم في أيّ كتلة شيفرة فارغة في أيّ قاعدة من قواعد اللغة.

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

class Human:
    name = 'Adam'
    age = 30

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

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

يلعب ذلك المعامِل في الحقيقة دورًا مركزيًا في أيّ دالة، إذ يمكِّنك من استدعاء أيّ دالة أخرى بداخل الكائن -أي الصنف- وأيضًا من استدعاء وتغيير قيم أيّ خاصية من الخاصيات في الكائن، وبناءً على ذلك فإننا سنستخدِم الدالة __init__ لتمرير قيم خاصيات الكائن عند إنشائه، والتي تُنفَّذ افتراضيًا عند الإنشاء لكي يتم تمرير قيم الخاصيات، ثم إعادة تعيينها في الكائن بأول معامل افتراضي تحدثنا عنه، وسنكتب في المثال التالي تلك الدالة، بحيث نكتب اسمًا للمعامل الأول والذي يفضَّل أن يكون self، ثم نبدأ في إضافة معامِلات لكل خاصية من خاصيات الكائن لتُعيَّن فيه.

class Human:
    name = 'Adam'
    age = 30
    def __init__(self, name, age):
        self.name = name
        self.age = age

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

إنشاء الكائنات والتعامل معها

عند إنشاء كائن جديد من صنف تمرَّر معامِلات دالة الإنشاء __init__، إذ تُنفَّذ تلك الدالة كما ذكرنا عند إنشاء كائن جديد، كما يُسنَد الكائن الجديد في متغير، إذ أنه يُعَد نوعًا جديدًا من أنواع البيانات الذي عرَّفته أنت بنفسك عند إنشاء صنف جديد.

ahmed = Human('Ahmed', 23)
print (ahmed.name); print (ahmed.age)
>> Ahmed
>> 23

حسنًا، ما حدث لا يزيد عن إنشاء متغير جديد يحمل الاسم ahmed من الصنف الذي كتبناه مسبقًا Human، والذي تحتاج دالة __init__ فيه إلى معاملين هما الاسم والعمر واللذين مرِّرا بين الأقواس بعد اسم الصنف في المثال السابق.

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

ahmed = Human('Ahmed', 23)
ahmed.age += 1
print (ahmed.age)
>> 24

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

class Human:
    name = 'Adam'
    def __init__(self, name):
        self.name = name
    def walk(self):
        print (self.name + ' is walking now ..')
ahmed = Human('Ahmed')
ahmed.walk()
>> Ahmed is walking now ..

نلاحظ أنه على الرغم من أنّ الدالة walk لا تطلب أيّ معامل، إلا أنه يمرَّر أول معامل افتراضيًا أسميناه self، والذي نستطيع من خلاله استدعاء أي دالة أو خاصية من الكائن، وذلك ما فعلناه لطباعة اسم الكائن عند طباعة الجملة.

وراثة الأصناف وإنشاء أصناف فرعية

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

لنكتب مثالًا يحتوي على صنف Programmer الذي يرث الصنف Human مع إضافة خاصية اللغة language التي تحمل بدورها اسم لغة البرمجة المتخصص فيها المبرمج، ثم سنعدِّل على دالة __init__ لاستقبال قيمة للخاصية الجديدة وهي اللغة، وبذلك نكون قد أنشأنا صنفًا فرعيًا وراثيًا، وأضفنا خاصيةً له، ثم عدّلنا على دالة من دوال الصنف الأب:

class Human:
    name = 'Adam'
    def __init__(self, name):
        self.name = name
    def walk(self):
        print (self.name + ' is walking now ..')
class Programmer(Human):
    language = 'PHP'
    def __init__(self, name, language):
        self.name = name; self.language = language
ahmed = Programmer('Ahmed', 'Python')
print (ahmed.language); ahmed.walk()
>> Python
>> Ahmed is walking now ..

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

اقرأ أيضًا

• المقال السابق: تعرف على أهم الدوال المدمجة في لغة بايثون
• دليلك إلى أنواع لغات البرمجة
• مفهوم البرمجة كائنية التوجه

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

ينسّق Black الشيفرات تلقائيًا في ملفات بايثون ذات اللاحقة ‎.py، ورغم ضرورة فهمك لقواعد التنسيق الواردة في المقال السابق، إلا أن Black وحده قادر على إجراء كافة عمليات التنسيق الفعلية، ففي حال كنت تعمل على مشروعٍ برمجي ضمن فريق، فسيوفّر عليكم استخدام Black الكثير من الجدالات حول كيفية تنسيق الشيفرات.

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

تثبيت الأداة Black

نثبّت Black باستخدام أداة تثبيت الحزم pip الافتراضية في بايثون. ولإجراء ذلك، في حال استخدامك لنظام التشغيل ويندوز، افتح نافذة سطر أوامر، واكتب ضمنها ما يلي:

C:\Users\Al\>python -m pip install --user black

أما إذا كنت تستخدم أحد نظاميّ ماك أو لينكس، فافتح نافذة موجه الأوامر مُستخدمًا الأمر python3 بدلًا من python كما هو الحال في ويندوز (الأمر الواجب مراعاته في كافّة تعليمات بايثون الواردة في هذا المقال):

$ python3 -m pip install --user black

ويعد الخيار m- مسؤولًا عن إعلام بايثون لتشغيل الوحدة pip كتطبيق، مع ملاحظة أن بعض الوحدات في بايثون مضبوطة لتعمل كتطبيق افتراضيًا.

ثمّ نتحقق من كون التثبيت قد تم بنجاح عبر تشغيل الأمر python -m black، وعندها يجب أن تظهر رسالة مفادها عدم وجود مسارات معطاة No paths given أو ما من شيء لفعله Nothing to do، بدلًا من ظهور رسالة تفيد بعدم وجود وحدة باسم black أو No module named black.

دورة تطوير التطبيقات باستخدام لغة Python

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

اشترك الآن

تشغيل Black من سطر الأوامر

من الممكن تشغيل المنسّق Black لأي ملف بايثون باستخدام سطر الأوامر، كما أنّ محررات النصوص وبيئات التطوير المتكاملة قادرة على تشغيل Black في الخلفية أثناء عملك ضمنها. وللحصول على التعليمات المتعلقة بكيفية تشغيل Black مع محررات نصوص مثل Jupyter و Visual Studio Code و PyCharm وغيرها، من خلال زيارة الصفحة الرئيسية للمنسّق Black على psf/black.

فعلى سبيل المثال، لنفرض أننا نريد تنسيق ملف باسم yourScript.py تلقائيًا، لذا نفتح نافذة سطر الأوامر ونكتب فيها الأمر التالي ونشغله (مع مراعاة تبديل الأمر python إلى python3 في حال استخدام أحد نظامي ماك أو لينكس):

C:\Users\Al>python -m black yourScript.py

وبمجرد تشغيل الأمر السابق، سينُسَق محتوى الملف yourScript.py وفقًا لقواعد تنسيق Black.

وفي حال كون متغير البيئة PATH مضبوطًا ليشغّل Black مباشرةً، عندها يكفي كتابة الشيفرة التالية لتنسيق الملف yourScript.py تلقائيًا:

C:\Users\Al>black yourScript.py

كما من الممكن جعل Black يعمل على كل الملفات ذات اللاحقة py. ضمن مجلد معين، وذلك بتحديد هذا المجلد ضمن الأمر بدلًا من تحديد اسم ملف معيّن، فمثلًا الأمر التالي في ويندوز سينسّق كافة الملفات ذات اللاحقة py. الموجودة ضمن المجلد C:\yourPythonFiles بما يتضمّن الملفات الموجودة في المجلدات الفرعية منه:

C:\Users\Al>python -m black C:\yourPythonFiles

فتحديد مجلد كامل لتنسيق ملفاته يعد خيارًا مفيدًا جدًا في حال كون مشروعك يتضمّن عدة ملفات بايثون، كبديل عن كتابة أمر خاص لتنسيق كل ملف وحده.

ورغم كون Black صارمًا في طريقة تنسيقه للشيفرات، إلا أن الفقرات الثلاث التالية تتضمّن بعض الخيارات الممكن تغيرها فيه، وللاطلاع على كامل الخيارات التي يوفرها Black، شغّل الأمر python -m black --help في نافذة سطر الأوامر.

تعديل إعدادات طول السطر في Black

إن الطول المعياري للسطر الواحد في بايثون هو 80 محرفًا، ويعود تاريخ الأسطر ذات الثمانين محرفًا إلى حقبة الحوسبة باستخدام البطاقات المُثقبّة punch cards في عشرينيات القرن الماضي، حين طرحت شركة IBM بطاقات مثقبة ذات 80 عمود و 12 سطر، ليستمر استخدام معيار الثمانين محرفًا في الطابعات والشاشات ونوافذ سطر الأوامر لعدّة عقود لاحقة.

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

يستخدم Black افتراضيًا أسطرًا ذات 88 محرفًا، مضيفًا 10% زيادة عن القيمة المعيارية (80 محرف)، أما عن تفضيلي الشخصي فهو 120 محرف للسطر، ولجعل Black ينسق الشيفرة جاعلًا الحد الأعظمي لطول السطر 120 محرفًا على سبيل المثال، نستخدم خيار سطر الأوامر l 120-، إذ يبدو الأمر في نظام ويندوز كما يلي:

C:\Users\Al>python -m black -l 120 yourScript.py

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

تعطيل إعداد حصر السلاسل النصية بعلامات اقتباس مزدوجة

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

a = 'Hello'
b = "Hello"
c = 'Al\'s cat, Zophie.'
d = 'Zophie said, "Meow"'
e = "Zophie said, \"Meow\""
f = '''Hello'''

وبتشغيل Black على الملف السابق، سينسقه ليصبح بالشكل:

1 a = "Hello"
b = "Hello"
c = "Al's cat, Zophie."
2 d = 'Zophie said, "Meow"'
e = 'Zophie said, "Meow"'
3 f = """Hello"""

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

ومن الجدير بالملاحظة أنه وباستخدام Black على الشيفرة السابقة فأن السلاسل النصية في المتغيرات a و b و c قد حُصرت ضمن علامات اقتباس مزدوجة، في حين بقيت علامة الاقتباس المفردة للسلسلة في المتغير d لتجنب الخلط مع العلامة المزدوجة الموجودة أصلًا ضمن السلسلة في السطر 2، كما نلاحظ أن Black قد استبدل علامات الاقتباس المفردة الثلاثية في السطر 3 الدالة على كون هذه السلسة متعددة الأسطر multiline، بعلامة اقتباس مزدوجة ثلاثية.

وفي حال رغبتك بترك علامات الاقتباس على حالها دون تغييرها من قبل Black، فاستخدم ضمن استدعاءه الخيار S- في نافذة سطر الأوامر (مع ملاحظة أنّ حرف S كبير هنا)، فعلى سبيل المثال، في حال تشغيل Black على الملف yourScript.py الأصلي في نظام ويندوز، سيظهر الخرج التالي:

C:\Users\Al>python –m black -S yourScript.py
All done!
1 file left unchanged.

كما من الممكن استخدام كلا خياري الحد الأقصى لمحارف السطر l- وخيار عدم تغيير علامات الاقتباس S- في سطرٍ واحد، بالشكل:

C:\Users\Al>python –m black –l 120 -S yourScript.py

استعراض التغييرات التي أجراها Black

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

ولعل الخيار البديل الأفضل هو معاينة التغييرات التي سيجريها Black قبل تطبيقها الفعلي من خلال تشغيل Black مع استخدام خيار سطر الأوامر diff--، والذي يبدو في نظام ويندوز بالشكل:

C:\Users\Al>python -m black --diff yourScript.py

سيعطي هذا الأمر خرجًا يمثّل التغييرات التي سيجريها Black في صياغة لبيان الاختلافات شبيهة بتلك شائعة الاستخدام في برمجيات إدارة الشيفرات، إلا أنها مقروءة وواضحة للبشر. فمثلًا لو تضمّن الملف yourScript.py السطر البرمجي[weights=[42.0,3.1415,2.718، وبتشغيل الخيار diff-- مع Black، سيكون الخرج بالشكل:

C:\Users\Al\>python -m black --diff yourScript.py
--- yourScript.py       2020-12-07 02:04:23.141417 +0000
+++ yourScript.py       2020-12-07 02:08:13.893578 +0000
@@ -1 +1,2 @@
-weights=[42.0,3.1415,2.718]
+weights = [42.0, 3.1415, 2.718]

تشير علامة الناقص إلى أن Black سيحذف السطر التالي:

weights=[42.0,3.1415,2.718]

ليستبدله إلى لسطر المشار إليه بعلامة الزائد، أي:

weights = [42.0, 3.1415, 2.718]

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

تعطيل عمل Black على أجزاء محددة من الشيفرة

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

# Set up constants for different time amounts:
SECONDS_PER_MINUTE = 60
SECONDS_PER_HOUR   = 60 * SECONDS_PER_MINUTE
SECONDS_PER_DAY    = 24 * SECONDS_PER_HOUR
SECONDS_PER_WEEK   = 7  * SECONDS_PER_DAY

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

# Set up constants for different time amounts:
SECONDS_PER_MINUTE = 60
SECONDS_PER_HOUR = 60 * SECONDS_PER_MINUTE
SECONDS_PER_DAY = 24 * SECONDS_PER_HOUR
SECONDS_PER_WEEK = 7 * SECONDS_PER_DAY

ولإعلام Black برغبتنا بعدم إجراء أي تغييرات على مقطع برمجي معيّن، يكفي حصره ما بين التعليقين fmt: off # و fmt: on #، ليتابع بعده إجراء التنسيقات بشكل طبيعي:

# Set up constants for different time amounts:
# fmt: off
SECONDS_PER_MINUTE = 60
SECONDS_PER_HOUR   = 60 * SECONDS_PER_MINUTE
SECONDS_PER_DAY    = 24 * SECONDS_PER_HOUR
SECONDS_PER_WEEK   = 7  * SECONDS_PER_DAY
# fmt: on

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

الخاتمة

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

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

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

ترجمة -وبتصرف- للجزء الثاني من الفصل الثالث Code Formatting With Black من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigarti.

اقرأ أيضًا

• المقال السابق: قواعد تنسيق الشيفرات ودور المنسق Black في بايثون
• بيئات التطوير IDE المستخدمة في تطوير تطبيقات بايثون
• كيفية استخدام سطر أوامر بايثون التفاعلي
• كيفية تنسيق النصوص في بايثون

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

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

فوضى شيفراتك ستفقدك أصدقائك وتنفر زملائك في العمل

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

spam = ['dog', 'cat', 'moose']

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

spam= [ 'dog'  ,'cat',"moose"]

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

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

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

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

الدليل الإرشادي PEP 8 لكيفية تنسيق الشيفرات

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

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

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

ونظرًا لاستخدامنا منسّق Black، فإن شيفراتنا ستتبع في تنسيقها دليل Black الإرشادي المتوافق تمامًا مع قواعد PEP 8. ولابد من تعلمك لهذه الأصول وكيفية تطبيقها يدويًا، فقد لا يكون منسّق Black متوفر دائمًا بسهولة، ناهيك عن كون القواعد التنسيقية التي ستتعلمها في هذا المقال عامّة وتتطبق على لغات البرمجة الأخرى، والتي قد لا تتضمّن منسقًا تلقائيًا.

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

دورة تطوير التطبيقات باستخدام لغة Python

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

اشترك الآن

التباعد الأفقي

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

استعمال مفتاح المسافة الفارغة Space لإنشاء مسافة بادئة

تعرّف المسافة البادئة بأنها ذلك الفراغ المتموضع في بداية أحد أسطر الشيفرة، ولإضافتها من الممكن استخدام أحد مفتاحي إضافة المحارف الفارغة في لوحة المفاتيح، وهما مفتاح المسافة الفارغة Space ومفتاح الجدولة Tab. ورغم كون أي منهما يؤدّي هذا الغرض، إلا أن استخدام مفتاح المسافة الفارغة يعد الإجراء الأفضل.

والسبب في ذلك يعود لكون كل من المفتاحين يعمل بطريقة مختلفة، ففي حين يُصيَّر مفتاح Space على الشاشة بهيئة قيمة محرفية تساوي فراغًا واحدًا بالشكل ‘ ‘، إلا أن مفتاح Tab يُصيّر على هيئة قيمة محرفية تقابل محرف الهروب t\ ما يجعل حجم الفراغات غامضًا، فعلى الغالب يعرض هذا المفتاح حجمًا متغيرًا للفراغات مُحددًا علامة جدولة ليبدأ النص التالي بعدها، إذا تتموضع علامة الجدولة عند كل ثمان فراغات وفقًا لعرض المستند، والمثال التالي يبيّن الفرق من خلال شيفرة مكتوبة في الصَدَفَة التفاعلية، إذ استخدمنا بدايةً مفتاح Space للفصل بين الكلمات ومن ثم مفتاح Tab:

>>> print('Hello there, friend!\nHow are you?')
Hello there, friend!
How are you?
>>> print('Hello\tthere,\tfriend!\nHow\tare\tyou?')
Hello   there,  friend!
How     are     you?

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

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

 TabError: inconsistent use of tabs and spaces in indentation 

دلالةً على الاستخدام غير المتناسق لعلامات الجدولة والفراغات في إنشاء المسافات البادئة، في حين أنّ المنسّق Black يحوّل أي علامة جدولة مضافة كمسافة بادئة إلى أربعة فراغات تلقائيًا.

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

def getCatAmount():
....numCats = input('How many cats do you have?')

....if int(numCats) < 6:

........print('You should get more cats.')

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

التباعد ضمن السطر الواحد

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

استخدم فراغ واحد ما بين العمليات والمعرفات

إن لم تترك فراغًا ما بين العمليات والمعرفات (المتغيرات، الدوال، الكائنات …)، ستبدو الشيفرة وكأنها متداخلة. فمثلًا السطر التالي يتضمّن فراغات ما بين العمليات والمتغيرات:

YES: blanks = blanks[:i] + secretWord[i] + blanks[i + 1 :]

وفي حال حذف تلك الفراغات، فسيبدو بالشكل:

NO:  blanks=blanks[:i]+secretWord[i]+blanks[i+1:]

تستخدم هذه الشيفرة في كلتا الحالتين معامل الجمع + لجمع ثلاثة قيم، ولكن في حالة عدم استخدام فراغات، قد يبدو معامل الجمع الموجود ضمن المتغير [:blanks[i+1 على أنّه عملية جمع رابعة، إلا أن استخدام الفراغات سيوضح أن معامل الجمع هذا جزء من قيمة الشريحة slice (بنية في بايثون تمكننا من الوصول إلى أجزاء من التسلسلات مثل السلاسل النصية والجداول والقوائم) الموجودة بين القوسين.

لا تضع مسافات قبل الفواصل وضع مسافة واحدة بعدها

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

YES: def spam(eggs, bacon, ham):
YES:     weights = [42.0, 3.1415, 2.718]

وإلا سينتهي الأمر بشيفرة مجمّعة ذات مقروئية منخفضة، كما يلي:

NO:  def spam(eggs,bacon,ham):
NO:      weights = [42.0,3.1415,2.718]

كما من الضروري عدم وضع مسافة قبل الفاصلة، لأن ذلك سيجذب النظر نحوه:

NO:  def spam(eggs , bacon , ham):
NO:      weights = [42.0 , 3.1415 , 2.718]

يضيف منسّق Black تلقائيًا مسافة بعد كل فاصلة، كما يحذف أي فراغات مُضافة قبلها.

لا تستخدم أي فراغات قبل أو بعد النقاط

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

YES: 'Hello, world'.upper()

أما في حال استخدام مسافة قبل النقطة أو بعدها، فقد يبدو الكائن وسمته غير مرتبطان، كما في الحالة:

NO:  'Hello, world' . upper()

يحذف منسق Black تلقائيًا أي مسافات قبل أو بعد النقاط.

لا تضع مسافات بعد أسماء الدوال أو التوابع أو حاويات البيانات

من السهل تمييز أسماء الدوال والتوابع كونها تُتبع دومًا بقوسين، لذا يجب عدم وضع مسافة بين اسم الدالة أو التابع وقوس البداية، فعادةً ما يتم استدعاء الدوال بالشكل:

YES: print('Hello, world!')

ومع استخدام مسافة قبل قوس البداية، قد يبدو استدعاء الدالة الواحدة على أنه أمران مستقلان، كما في المثال:

NO:  print ('Hello, world!')

لذا يحذف منسّق Black أي مسافات بين اسم الدالة أو التابع وقوس بدايتها.

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

YES: spam[2]
YES: spam[0:3]
YES: pet['name']

ومع إضافة مسافات قد تبدو الشيفرة مجددًا وكأنها أمران منفصلان:

NO:  spam [2]
NO:  spam    [0:3]
NO:  pet ['name']

لذا يحذف منسّق Black أي مسافات كائنة بين اسم المتغير وقوس البداية المعقوف.

لا تضع مسافات بعد أقواس البداية أو قبل أقواس النهاية بأنواعها

يجب عدم استخدام مسافات في فصل الأقواس بأنواعها الهلالية () والمعقوصة {} والمعقوفة [] عن محتوياتها، فيجب أن تبدأ المعاملات في عبارة تصريح عن دالة ما أو القيم ضمن قائمة بعد قوس بدايتها وتنتهي قبل قوس نهايتها مباشرةً.

YES: def spam(eggs, bacon, ham):
YES:     weights = [42.0, 3.1415, 2.718]

إذ يجب عدم إضافة أي مسافات بعد قوس البداية أو قبل قوس النهاية، سواء كانت هذه الأقواس هلالية أم معقوفة:

NO:  def spam( eggs, bacon, ham ):
NO:      weights = [ 42.0, 3.1415, 2.718 ]

فإضافة هذه الأقواس لا يحسّن من مقروئية الشيفرة وبالتالي لا تقدّم أي قيمة مضافة، لذا يحذف منسّق Black هذه المسافات تلقائيًا في حال وجودها.

ضع فراغين قبل تعليقات نهاية السطر

إن أردت إضافة تعليق إلى نهاية أحد أسطر الشيفرة، فيجب إضافة مسافتين بعد نهاية السطر البرمجي وقبل المحرف # الدال على بداية التعليق، كما في المثال:

YES: print('Hello, world!')  # Display a greeting.

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

NO:  print('Hello, world!') # Display a greeting.
NO:  print('Hello, world!')# Display a greeting.

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

التباعد الرأسي

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

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

NO:  class ExampleClass:
         def exampleMethod1():
             pass
         def exampleMethod2():
             pass
     def exampleFunction():
         pass

لتصبح تلقائيًا بالشكل:

YES: class ExampleClass:
         def exampleMethod1():
             pass

         def exampleMethod2():
             pass


     def exampleFunction():
         pass

مثال على التباعد الرأسي

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

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

--snip--
    def __call__(self, value):
    1 if not value or '@' not in value:
            raise ValidationError(self.message, code=self.code)

    2 user_part, domain_part = value.rsplit('@', 1)

    3 if not self.user_regex.match(user_part):
            raise ValidationError(self.message, code=self.code)

    4 if (domain_part not in self.domain_whitelist and
                not self.validate_domain_part(domain_part)):
            # Try for possible IDN domain-part
            try:
                domain_part = punycode(domain_part)
            except UnicodeError:
                pass
            else:
                if self.validate_domain_part(domain_part):
                    return
            raise ValidationError(self.message, code=self.code)
--snip--

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

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

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

أفضل الممارسات حيال التباعد الرأسي

لعل إحدى ميزات بايثون غير المعروفة على نطاق واسع هي إمكانية الفصل بين عدة عبارات في السطر واحد باستخدام الفاصلة المنقوطة، بمعنى أنّه مثلًا من الممكن كتابة السطرين:

print('What is your name?')
name = input()

على سطر واحد بشرط الفصل بينهما بفاصلة منقوطة:

print('What is your name?'); name = input()

وكما هو الحال مع استخدام الفاصلة العادية، يجب عدم إضافة مسافة قبل الفاصلة المنقوطة، وإضافة مسافة واحدة بعدها.

أمّا بالنسبة للعبارات البرمجية التي تنتهي بنقطتين رأسيتين، كعبارات if و for و while و def أو جمل بناء الأصناف، فمن الممكن كتابتها على سطر واحد، فمثلًا من الممكن كتابة استدعاء الدالة ()print في الشيفرة التالية:

if name == 'Alice':
    print('Hello, Alice!')

على نفس السطر مع العبارة الشرطية if، بالشكل:

if name == 'Alice': print('Hello, Alice!')

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

وكذلك الأمر بالنسبة لاستيراد الوحدات، إذ من الممكن استيراد عدة وحدات باستخدام أمر واحد في سطر واحد، كما في المثال:

import math, os, sys

ومع ذلك، فإن الدليل PEP 8 يوصي بفصل هذه العبارات، لتتم عملية استيراد كل وحدة في سطر مستقل، بالشكل:

import math
import os
import sys

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

كما ينصح الدليل PEP 8 بتجميع عبارات الاستيراد ضمن ثلاث مجموعات، كما يلي:

• الوحدات من مكتبة بايثون المعيارية، مثل الوحدة math و os و sys.
• الوحدات الخارجية، مثل Selenium و Requests و Django.
• الوحدات الداخلية التي تمثّل جزءًا من البرنامج.

وإجمالًا لا يغير منسق Black من تنسيق الاستيرادات في الشيفرة، نظرًا لكون الإرشادات المتعلقة بالاستيرادات اختيارية.

الخاتمة

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

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

إن تنسيق الشيفرات يدويًا ضمن المحررات قد تكون مهمَّة مملة، إذ من الممكن أتمتتها باستخدام أداة مثل Black.

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

لقد استعرضنا في هذا المقال التنسيقات الأساسية التي يجريها Black، ويمكنك الاطلاع على دليل Black الإرشادي لكامل التنسيقات بزيارة black.readthedocs.io.

ترجمة -وبتصرف- للجزء الأول من الفصل الثالث Code Formatting With Black من كتاب Beyond the Basic Stuff with Python لصاحبه Al Sweigarti.

اقرأ أيضًا

• المقال السابق: متغير البيئة PATH والعمل دون نافذة سطر الأوامر في بايثون
• أساسيات البرمجة بلغة بايثون
• كيفية تنسيق النصوص في بايثون 3
• كيفية استخدام آلية تنسيق السلاسل النصية في بايثون 3

تعرفنا في المقال السابق على مفهوم الدوال وكيف يمكن للمبرمج تعريف دوال مخصصة ولكن لا يحتاج المبرمج إلى تعريف كل الدوال بنفسه من الصفر بل توجد الكثير من الدوال المدمجة بالفعل في اللغة افتراضيًا تسمى Built-in Functions أي دوال مدمَجة، وأفضل الأمثلة عليها هي دالة الطباعة print الموجودة افتراضيًا في بايثون، وسنذكر في هذا الفصل أهم هذه الدوال وأمثلة على استخدامها.

دوال التعامل مع الأوقات والأزمنة في بايثون

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

توجد في بايثون بعض الوحدات Modules التي تُستخدَم عند التعامل مع الأوقات والتواريخ، سنبدأ أولًا بوحدة الوقت التي تُدعى time وهي تحتوي على الكثير من الدوال المفيدة للتعامل مع الوقت وسنذكر بعضًا منها.

ملاحظة: يُحسَب في بايثون وفي كثير من لغات البرمجة وقت الثانية الحالية حسب فترة بُعدها بالثواني عن الساعة 12 صباحًا يوم 1 من شهر 1 عام 1970م، وهو نظام متعارف عليه، إذ يُعَدّ ذلك التاريخ نقطة انطلاق ما يُدعى بوقت يونكس Unix أو Unix Epoch.

دالة time

يمكننا تحديد رقم الثانية الحالية باستخدام الدالة time الموجودة في الوحدة time، إذ سنطبع في المثال التالي الوقت الحالي كما يلي:

import time

print (time.time())
>> 1592952455.39395

ستلاحظ في كل مرة يُنفَّذ المثال أعلاه أن العدد يزيد بفرق عدد الثواني بين التنفيذ الثاني والتنفيذ الأول، والجدير بالذكر أنّ الثانية في تلك القاعدة يُطلق عليها بالإنجليزية لقب Tick، وحسب تلك القاعدة فإنه يعبَّر عن التاريخ حسب عدد الثواني، إذ يمثِّل العدد الموجب عدد ثواني المارة على تاريخ 1/1/1970؛ أما العدد السالب، فيُمثِّل عدد الثواني المطلوبة للوصول إلى وقت يونكس أي تاريخ 1 شهر 1 عام 1970م في حال تعاملنا مع تاريخ قديم، ولفهم ما نعنيه يمكن تخيُّل تاريخ وقت يونكس هو نقطة الصفر بحيث تمثِّل القيمة الموجبة ما بعد ذلك التاريخ؛ أما القيمة السالبة، فتمثِّل ما قبل ذلك التاريخ كما في الصورة التالية:

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

دالة localtime

يمكننا في بايثون معرفة التاريخ الحالي عبر دالة localtime وفي المثال الآتي نوضِّح كيفية استخدامها.

import time
print (time.localtime());
>> time.struct_time(tm_year=2020, tm_mon=6, tm_mday=24, tm_hour=23, tm_min=23, tm_sec=55, tm_wday=2, tm_yday=176, tm_isdst=0)