ما هو اصطلاح التسمية في Python لأسماء المتغيرات والدوال؟



Answers

يحتوي دليل Google Python Style على الاتفاقية التالية:

module_name، package_name، ClassName، method_name، ExceptionName، function_name، GLOBAL_CONSTANT_NAME، global_var_name، instance_var_name، function_parameter_name، local_var_name

يجب تطبيق نظام تسمية مشابه على CLASS_CONSTANT_NAME

Question

عادة ما تكون اتفاقية التسمية للمتغيرات وأسماء الطرق هي القادمة من خلفية C # إما CamelCase أو Pascal Case:

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

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

# python example
this_is_my_variable = 'a'
def this_is_my_function():

هل هناك نمط ترميز نهائي أكثر تفضيلاً لبيثون؟




عادةً ما يكون نمط الترميز جزءًا من معايير السياسة / الاتفاقية الداخلية للمؤسسة ، ولكنني أعتقد بشكل عام أن نمط all_lower_case_underscore_separator (يسمى أيضًا snake_case) هو الأكثر شيوعًا في python.




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

أنا ببساطة أحب CamelCase أفضل لأنه يتناسب بشكل أفضل مع طريقة تسمية الفئات ، يبدو أكثر منطقية لديك SomeClass.doSomething() من SomeClass.do_something() . إذا نظرت حولك في مؤشر الوحدة النمطية العالمي في python ، فسوف تجد كلاهما ، والذي يرجع إلى حقيقة أنه مجموعة من المكتبات من مصادر متنوعة نمت ساعات العمل الإضافية وليس شيئًا تم تطويره بواسطة شركة واحدة مثل Sun مع قواعد تشفير صارمة . أود أن أقول أن خلاصة القول هي: استخدام ما تريد على نحو أفضل ، انها مجرد مسألة الذوق الشخصي.




كما ذكرنا ، يقول PEP 8 لاستخدام lower_case_with_underscores للمتغيرات والطرق والوظائف.

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




كما يعترف دليل الأسلوب لبيثون كود ،

اصطلاحات تسمية مكتبة بايثون هي نوع من الفوضى ، لذا لن نحقق ذلك بشكل ثابت

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

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

لا تتردد في إقالتي كمهرط. :-) مثل OP ، أنا لست "Pythonista" ، ليس بعد على أي حال.




Links