Общий стиль кодирования для Python? - PullRequest
Новая
       35

Общий стиль кодирования для Python?

11 голосов
/ 12 мая 2010

Я довольно новичок в Python и хочу разработать свой первый серьезный проект с открытым исходным кодом. Я хочу спросить, каков общий стиль кодирования для проектов Python. Я также поставлю то, что я делаю прямо сейчас.

1.- Какова наиболее широко используемая ширина столбца? (вечный вопрос)
Я в настоящее время придерживаюсь 80 столбцов (и это боль!)

2.- Какие цитаты использовать? (Я видел все, и PEP 8 не упоминает ничего ясного)
Я использую одинарные кавычки для всего, кроме строк документации, которые используют тройные двойные кавычки.

3.- Где я могу разместить свой импорт?
Я помещаю их в заголовок файла в следующем порядке. 

import sys
import -rest of python modules needed-

import whatever
import -rest of application modules-

<code here>

4.- Могу ли я использовать "import what.function as blah"?
Я видел некоторые документы, которые игнорируют это.

5.- Вкладки или пробелы для отступа?
В настоящее время используется 4 пробела.

6.- Стиль именования переменной? Я использую строчные буквы для всего, кроме классов, которые я поместил в camelCase.

Что бы вы порекомендовали?

Ответы [ 3 ]

19 голосов
/ 12 мая 2010

PEP 8 в значительной степени является «корнем» всех общих руководств по стилю.

Google Руководство по стилю Python содержит некоторые части, которые хорошо продуманы, но другие являются своеобразными (отступы из двух пробелов вместо популярных четырех пробелов и стиль CamelCase для функций и методов). вместо стиля camel_case, это довольно важные особенности).

На ваши конкретные вопросы:

1.- Какова наиболее широко используемая ширина столбца? (вечный вопрос) Я в настоящее время придерживаюсь 80 столбцов (и это боль!)

80 столбцов является самым популярным

2.- Какие цитаты использовать? (Я видел все, и PEP 8 не упоминает что-нибудь понятно) я пользуюсь синглом цитаты для всего, кроме строк документации, которые используют тройные двойные кавычки.

Я предпочитаю стиль, который вы используете, но даже Google не смог достичь консенсуса по этому поводу: - (

3.- Где я могу разместить свой импорт? Я помещаю их в заголовок файла в этом заказ.

import sys import -rest of python необходимые модули-

импорт независимо от импорта прикладные модули-

Да, отличный выбор, и популярный тоже.

4.- Могу ли я использовать "import any.function as blah"? Я видел некоторые документы, которые игнорируют это.

Я настоятельно рекомендую всегда импортировать модули, а не конкретные имена внутри модуля. Это не просто стиль - есть сильные преимущества, например в тестируемости при этом. Предложение as подходит для сокращения имени модуля или предотвращения конфликтов.

5.- Вкладки или пробелы для отступа? В настоящее время используется 4 пробела.

В подавляющем большинстве самых популярных.

6.- Стиль именования переменной? Я использую строчные буквы для всего, кроме классов, который я положил в CamelCase.

Почти все называют классы заглавными буквами и константы заглавными.

2 голосов
/ 12 мая 2010

1.- В наши дни большинство людей имеют монитор 16: 9 или 16:10. Даже если у них нет широкоформатного экрана, у них много пикселей, 80 столбцов - не такая уж большая проблема, как если бы все взламывали командную строку в окне удаленного терминала на мониторе 4: 3 со 320 X 240. Обычно я заканчиваю линию, когда она становится слишком длинной, что субъективно. Я нахожусь в 2048 X 1152 на 23-дюймовом Мониторе X 2.

2.- Одиночные кавычки по умолчанию, поэтому вам не нужно экранировать двойные кавычки, двойные кавычки, когда вам нужно встроить одинарные кавычки, и тройные кавычки для строк со встроенными символами новой строки.

3.- Поместите их в верхнюю часть файла, иногда вы помещаете их в функцию main , если они не нужны глобально для модуля.

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

В случае сомнений обратитесь к PEP 8 , исходному коду Python, существующим соглашениям в базе кода. Но самое важное - это быть внутренне согласованным , насколько это возможно. Весь код Python должен выглядеть так, как если бы это было возможно, написан одним и тем же человеком.

1 голос
/ 12 мая 2010

Поскольку я действительно без ума от "стиля", я напишу рекомендации, которые я в настоящее время использую в проекте SLOC объемом около 8 тыс. С примерно 35 файлами, большинство из которых соответствует PEP8.

  1. PEP8 говорит 79 (WTF?), Я иду с 80, и я уже привык к этому. Меньше движения глаз в конце концов!

  2. Строки документов и прочее, занимающее несколько строк в '' '. Все остальное в ''. Кроме того, мне не нравятся двойные кавычки, я все время использую только одинарные кавычки ... думаю, это потому, что я пришел из угла JavaScript, где его тоже проще использовать '', потому что таким образом вам не нужно избегать всех HTML материал: O

  3. Во главе, встроенный перед пользовательским кодом приложения. Но я также придерживаюсь подхода «ранний сбой», поэтому, если есть что-то, что зависит от версии (например, GTK), я сначала импортирую это.

  4. Зависит, в большинстве случаев, я использую import foo и импорт foo, но в некоторых случаях (например, имя уже определено другим импортом) я также использовал панель импорта foo как bla.

  5. 4 пробела. Период. Если вы действительно хотите использовать вкладки, убедитесь, что преобразовали их в пробелы перед фиксацией при работе с SCM. НО (НИКОГДА (!) СМЕШИВАТЬ ТАБЛИЦЫ И ПРОСТРАНСТВА !!! Это может и внесет ужасные ошибки.

  6. some_method или foo_function, CONSTANT, 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 ...

Но это только мои 2 цента.

...