نمط الترميز الشائع للبيثون؟

Question

أنا جديد جدًا على Python ، وأريد تطوير أول مشروع خطير مفتوح المصدر. أريد أن أسأل ما هو أسلوب الترميز المشترك لمشاريع بيثون. سأضع أيضًا ما أفعله الآن.

1.- ما هو عرض العمود الأكثر استخدامًا؟ (السؤال الأبدي)
أنا حاليًا متمسك بـ 80 عمودًا (وهو ألم!)

2.- ما هي الاقتباسات لاستخدامها؟ (لقد رأيت كل شيء ولا يذكر Pep 8 أي شيء واضح)
أنا أستخدم عروض أسعار واحدة لكل شيء ما عدا docstrings ، والتي تستخدم عروض أسعار مزدوجة ثلاثية.

3.- أين أضع وارداتي؟
أنا أضعهم في رأس الملف في هذا الترتيب.

import sys
import -rest of python modules needed-

import whatever
import -rest of application modules-

<code here>

4.- هل يمكنني استخدام "استيراد مهما مثل بلاه "؟
رأيت بعض المستندات التي تتجاهل القيام بذلك.

5.- علامات التبويب أو المساحات للمسافة البادئة؟
حاليا باستخدام 4 مسافات علامات تبويب.

6.- نمط التسمية المتغير؟ أنا أستخدم الأحرف الصغيرة لكل شيء ما عدا الفصول الدراسية ، التي وضعتها في Camelcase.

أي شيء تنصحه؟

Answer 1

بيب 8 هو إلى حد كبير "الجذر" لجميع أدلة النمط الشائع.

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

إلى أسئلتك المحددة:

1.- ما هو عرض العمود الأكثر استخدامًا؟ (السؤال الأبدي) أنا متمسك حاليًا بـ 80 عمودًا (وهو ألم!)

80 عمود هو الأكثر شعبية

2.- ما هي الاقتباسات لاستخدامها؟ (لقد رأيت كل شيء ولا يذكر Pep 8 أي شيء واضح) أنا أستخدم عروض أسعار واحدة لكل شيء ما عدا docstrings ، والتي تستخدم عروض الأسعار المزدوجة الثلاثية.

أفضل الأسلوب الذي تستخدمه ، ولكن حتى Google لم تكن قادرة على التوصل إلى توافق في الآراء حول هذا :-(

3.- أين أضع وارداتي؟ أنا أضعهم في رأس الملف في هذا الترتيب.

استيراد SYS Import -rest من وحدات Python اللازمة-

استيراد مهما كان استيراد وحدات التطبيق-

نعم ، اختيار ممتاز ، وشعبية أيضا.

4.- هل يمكنني استخدام "استيراد أي شيء. رأيت بعض المستندات التي تتجاهل القيام بذلك.

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

5.- علامات التبويب أو المساحات للمسافة البادئة؟ حاليا باستخدام 4 مسافات علامات تبويب.

الأكثر شعبية.

6.- نمط التسمية المتغير؟ أنا أستخدم الأحرف الصغيرة لكل شيء ما عدا الفصول الدراسية ، التي وضعتها في Camelcase.

يسمي الجميع تقريبًا فصولًا بأحرف كبيرة أولية والثوابت مع All-ApperCase.

Answer 2

1.- معظم كل شخص لديه شاشة 16: 9 أو 16:10 الآن أيام. حتى لو لم يكن لديهم شاشة واسعة ، فإن لديهم الكثير من وحدات البكسل ، فإن 80 كولز ليست عبارة عن عروض صفقات عملية كبيرة كما كان عندما كان الجميع يتسللون في خط الأوامر في نافذة طرفية بعيدة على شاشة 4: 3 على 320 × 240. عادةً ما أنهي الخط عندما يزداد وقتًا كبيرًا ، وهو أمر شخصي. أنا في 2048 × 1152 على 23 "شاشة × 2.

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

3.- ضعها في الجزء العلوي من الملف ، وأحيانًا تضعها في الأساسية الوظيفة إذا لم تكن هناك حاجة إليها على مستوى العالم للوحدة.

4.- إنه تعبير شائع لإعادة تسمية بعض الوحدات النمطية. مثال جيد هو ما يلي.

try:
    # for Python 2.6.x
    import json
except ImportError:
    # for previous Pythons
    try:
        import simplejson as json
    except ImportError:
        sys.exit('easy_install simplejson')

لكن الطريقة المفضلة لاستيراد فئة أو وظيفة فقط from module import xxx مع الاختياري as yyy إذا لزم الأمر

5.- دائما استخدام المساحات! 2 أو 4 طالما لا توجد علامات تبويب

6.- يجب أن تصل الفئات إلى UpperCaseCamelStyle ، تكون المتغيرات صغيرة في بعض الأحيان lowercamelcase أو في بعض الأحيان all_lowecase_separated_by_underscores ، وكذلك أسماء الوظائف. يجب أن تكون "الثوابت" all_upper_case_separated_by_underscores

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

Answer 3

نظرًا لأنني مجنونة حقًا بشأن "التصميم" ، سأكتب الإرشادات التي أستخدمها حاليًا في مشروع قرب 8K SLOC مع حوالي 35 ملفًا ، معظمها يتطابق مع PEP8.

1. PEP8 يقول 79 (WTF؟) ، أذهب مع 80 وأنا معتاد على ذلك الآن. حركة العين أقل بعد كل شيء!

2. docstrings والأشياء التي تمتد خطوط متعددة في "''. كل شيء آخر في ''. كما أنني لا أحب عروض الأسعار المزدوجة ، فأنا أستخدم عروض أسعار مفردة فقط طوال الوقت ... أعتقد أن ذلك لأنني جئت من زاوية JavaScript ، حيث يكون من الأسهل استخدامه "، لأنه بهذه الطريقة لا تضطر إلى الهروب من الجميع الاشياء HTML: س

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

4. يعتمد ، في معظم الأوقات التي أذهب إليها مع استيراد FOO ومن FOO Import ، ولكن هناك حالات معينة (على سبيل المثال ، تم تعريف الاسم بالفعل بواسطة استيراد آخر) هل كنت أستخدمها من شريط استيراد FOO مثل BLA أيضًا.

5. 4 مسافات. فترة. إذا كنت ترغب حقًا في استخدام علامات التبويب ، فتأكد من تحويلها إلى مسافات قبل الالتزام عند العمل مع SCM. ولكن لا (!) خلط علامات التبويب والمساحات !!! يمكن أن تقدم الأخطاء الرهيبة.

6. some_method أو foo_function ، ثابت ، myClass.

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

# always insert a newline after a wrapped one
from bla import foo, test, goo, \
                another_thing

def some_method_thats_too_long_for_80_columns(foo_argument, bar_argument, bla_argument,
                                              baz_argument):

    do_something(test, bla, baz)

    value = 123 * foo + ten \
            - bla

    if test > 20 \
       and x < 4:

        test_something()

    elif foo > 7 \
         and bla == 2 \
         or me == blaaaaaa:

        test_the_megamoth()

كما أن لدي بعض الإرشادات لعمليات المقارنة ، أستخدم دائمًا is(not) للتحقق ضد None True False وأنا لا أقوم بمقارنة منطقية ضمنية مثل if foo:, ، أفعل دائما if foo is True:, ، الكتابة الديناميكية لطيفة ، لكنني في بعض الحالات أريد فقط أن أتأكد من أن الشيء يفعل الشيء الصحيح!

شيء آخر أقوم به هو عدم استخدام سلاسل فارغة! هم في ملف ثوابت ، في بقية الكود لدي أشياء مثل username == UNSET_USERNAME أو label = UNSET_LABEL انها مجرد وصفية بهذه الطريقة!

لديّ أيضًا بعض الإرشادات الصارمة للمساحة البيضاء وغيرها من الأشياء المجنونة ، لكني أحب ذلك (لأنني مجنونة بذلك) ، حتى أنني كتبت نصًا يتحقق من الكود الخاص بي:
http://github.com/bonsaiden/atarashii/blob/master/checkstyle

تحذير (!): سيؤذي مشاعرك! حتى أكثر من JSlint ...

لكن هذا مجرد سنتان.