ما هو اصطلاح التسمية في بيثون متغير وظيفة الأسماء ؟

Question

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

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

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

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

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

Answer 1

وانظر بيثون PEP 8 .

<اقتباس فقرة>   يجب أن تكون

وأسماء وظيفة صغيرة،   بكلمات مفصولة سفلية كما   من الضروري تحسين إمكانية القراءة.

     

ويسمح mixedCase فقط في سياقات   حيث أن هذا بالفعل السائدة   أسلوب

والمتغيرات ...

<اقتباس فقرة>   

استخدم وظيفة قواعد التسمية:   أحرف صغيرة مع الكلمات مفصولة   يؤكد الضرورة لتحسين   سهولة القراءة.

وأنا شخصيا تحيد عن هذا لأنني كما يفضل mixedCase على lower_case للمشاريع الخاصة.

Answer 2

دليل نمط بيثون جوجل لديه اتفاقية التالية:

<اقتباس فقرة>   

وMODULE_NAME، PACKAGE_NAME، اسم_الفئة، METHOD_NAME، ExceptionName،   FUNCTION_NAME، GLOBAL_CONSTANT_NAME، global_var_name،   instance_var_name، function_parameter_name، local_var_name

وينبغي تطبيق نظام تسمية مشابهة لCLASS_CONSTANT_NAME

Answer 3

ديفيد Goodger (في "كود مثل Pythonista" هنا) يصف بيب 8 التوصيات على النحو التالي:

• joined_lower عن وظائف الطرق ، سمات المتغيرات

• joined_lower أو ALL_CAPS بالنسبة الثوابت

• StudlyCaps لفئات

• camelCase فقط لتتوافق مع قبل الاتفاقيات القائمة

Answer 4

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

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

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

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

^{لا تتردد في رفض لي زنديق.:-) مثل OP, أنا لست "Pythonista" ليس بعد على أي حال.}

Answer 5

وهناك href="http://www.python.org/dev/peps/pep-0008/" PEP 8 ، كما تظهر إجابات أخرى، ولكن PEP 8 ما هو إلا دليل الأسلوب للمكتبة القياسية، وانها اتخذت فقط كما الإنجيل فيه. واحدة من الانحرافات الأكثر شيوعا من PEP (8) لأجزاء أخرى من التعليمات البرمجية هي تسمية متغير، وتحديدا للطرق. لا يوجد نمط السائد واحد، على الرغم من أن النظر في حجم التعليمات البرمجية التي تستخدم mixedCase، إذا كان للمرء أن يجعل فإن تعداد واحد صارم ربما في نهاية المطاف مع نسخة من PEP 8 مع mixedCase. هناك القليل الانحراف الأخرى من PEP 8 هذا هو تماما كما هو شائع.

Answer 6

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

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

Answer 7

وأنا شخصيا أحاول استخدام CamelCase لفئات وأساليب mixedCase وظائف. المتغيرات وعادة ما تكون تؤكد منفصلة (عندما أتذكر). بهذه الطريقة استطيع ان اقول في لمحة بالضبط ما ادعو وليس كل ما تبحث نفسه.

Answer 8

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

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

Answer 9

كذلك ما @JohnTESlade وقد أجاب. Google python دليل نمط لديه بعض أنيق جدا توصيات ،

أسماء لتجنب

• حرف واحد من الأسماء باستثناء عدادات أو التكرار
• شرطات (-) في أي حزمة/وحدة نمطية اسم
• \__double_leading_and_trailing_underscore__ names (محجوز من قبل الثعبان)

اصطلاح التسمية

• "الداخلية" يعني الداخلية إلى وحدة أو المحمية أو خاصة داخل الصف.
• يتبع واحد بتسطير أسفل السطر (_) لديها بعض الدعم من أجل حماية وحدة المتغيرات والوظائف (غير المدرجة مع الواردات * من).يتبع مزدوج أسفل السطر (__) أن متغير مثيل أو أسلوب فعال يعمل على جعل متغير أو طريقة خاصة إلى الدرجة (باستخدام اسم من الضغط).
• المكان ذات فئات أعلى مستوى الوظائف معا في وحدة نمطية.على عكس جافا ، هناك حاجة إلى تحد نفسك على صف واحد لكل وحدة.
• استخدام CapWords عن أسماء فئة ، ولكن lower_with_under.py عن أسماء الوحدة النمطية.على الرغم من أن هناك العديد من الوحدات الموجودة اسمه CapWords.py, هذا هو الآن بالإحباط لأن الأمر محير عند وحدة يحدث أن تكون سميت فئة.("انتظر ... هل أنا أكتب import StringIO أو from StringIO import StringIO?")

المبادئ المستمدة من غيدو التوصيات

Answer 10

وهناك ورقة حول هذا: HTTP: // شبكة الاتصالات العالمية .cs.kent.edu / ~ jmaletic / ورقات / ICPC2010-CamelCaseUnderScoreClouds.pdf

وTL، DR تقول ان snake_case هو أكثر قابلية للقراءة من camelCase. هذا هو السبب في استخدام اللغات الحديثة (أو ينبغي أن تستخدم) ثعبان أينما كانوا يستطيعون.

Answer 11

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

Answer 12

وعادة، واحد اتبع الاتفاقيات المستخدمة في المكتبة القياسية اللغة و.