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

ورقة الغش في الباندا

ورقة الغش لأوامر Git

أهم 50 سؤالًا في مقابلات SQL

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

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

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

النصيحة 4: المبادئ المفتوحة والمغلقة
ينص مبدأ الفتح المغلق (OCP) على أن الفئة أو الطريقة أو الوظيفة يجب أن تكون مفتوحة للتوسيع وليس للتعديل. وهذا يعني أن أي فئة أو طريقة أو وظيفة محددة يمكن إعادة استخدامها أو توسيعها بسهولة لمثيلات متعددة دون تغيير الكود الخاص بها.
وهذا لا يلتزم بـ OCP لأنه كلما كان هناك بلد جديد، سنحتاج إلى كتابة بيان if جديد لاستكمال ذلك. قد يبدو هذا بسيطًا الآن، لكن تخيل أن لدينا 100 دولة أو أكثر يجب أن نأخذها بعين الاعتبار. كيف سيبدو ذلك؟

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

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

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

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

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

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

الآن، ما تفعله هو أن لديك 50 طلبًا في أماكن مختلفة - برنامج SQL النصي الخاص بك (اختر أفضل 50 * من الطلبات)، وموقع الويب الخاص بك (آخر 50 طلبًا)، وتسجيل الدخول لطلبك (من أجل (i = 0; i

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

النصيحة 8: تجنب مسارات الترميز الثابت
الامتناع عن مسارات الملفات أو عناوين URL ذات التشفير الثابت؛ استخدم ملفات التكوين أو متغيرات البيئة بدلاً من ذلك.

النصيحة 9: يجب أن تكون الفصول الدراسية صغيرة
نعم! يجب أن تكون الفصول صغيرة قدر الإمكان. تمامًا مثل الوظائف.

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

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

يعيدنا هذا إلى SRP (مبدأ المسؤولية الفردية) الذي ينص على أن الفصل يجب أن يكون لديه سبب واحد فقط - مسؤولية واحدة - للتغيير.

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