Стандарты / передовые методы программирования Python [закрыто]

В python вы обычно используете PEP 8 - Style Guide for Python Code в качестве стандартов / рекомендаций по кодированию? Какие другие формализованные стандарты вы предпочитаете?

«В Python вы обычно используете PEP 8 - Руководство по стилю кода Python в качестве стандартов / рекомендаций по кодированию? Есть ли другие формализованные стандарты, которые вы предпочитаете?»

Как уже упоминалось, вы следуете PEP 8 для основного текста и PEP 257 для соглашений о строках документации.

Вместе с руководствами по стилю Python я предлагаю вам обратиться к следующему:

1. Код как Pythonista: идиоматический Python
2. Общие ошибки и бородавки
3. Как не писать код на Python
4. Python gotcha

Я следую рекомендациям Роба Найта в Python идиомах и эффективности . Я думаю, что они точно такие же, как PEP 8, но более синтетические и основанные на примерах.

Если вы используете wxPython, вы также можете проверить Руководство по стилю для кода wxPython , написанное Крисом Баркером.

Я очень строго придерживаюсь PEP-8.

Есть три конкретные вещи, которые я не побеспокоюсь изменить на PEP-8.

• Избегайте лишних пробелов сразу внутри скобок, скобок или фигурных скобок.

  Похожие: spam(ham[1], {eggs: 2})

  Я все равно так делаю: spam( ham[ 1 ], { eggs: 2 } )

  Зачем? Более 30 лет укоренившейся привычки противостоять snuggling () именам функций или (в C) ключевым словам операторов. Начиная с Fortran IV в 70-х гг.

• Используйте пробелы вокруг арифметических операторов:

  Похожие: x = x * 2 - 1

  Я все равно так делаю: x= x * 2 - 1

  Зачем? Грис «Наука программирования» предложил это как способ подчеркнуть связь между присваиванием и переменной, состояние которой изменяется.

  Он не подходит для множественного или расширенного назначения, для этого я использую много пробелов.

• Для имен функций, имен методов и имен переменных экземпляра

  Рекомендуется: строчные буквы, слова разделены подчеркиванием по мере необходимости для улучшения читаемости.

  Я все равно так делаю: camelCase

  Зачем? Более 20 лет укоренившейся привычки к camelCase, начиная с Pascal в 80-х.

PEP 8 хорош, единственное, что мне хотелось бы усложнить, - это священная война Tabs-vs-Spaces.

В основном, если вы начинаете проект на python, вам нужно выбрать Tabs или Spaces, а затем расстрелять всех нарушителей на месте.

Чтобы добавить Бхадры список идиоматических гидов:

Ознакомьтесь с презентацией Энтони Бакстера по эффективному программированию на Python (из OSON 2005).

Отрывок:

# dict's setdefault method turns this:
if key in dictobj:
    dictobj[key].append(val)
else:
    dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)

Я слежу за этим очень строго. Единственный бог до PEP-8 - существующие кодовые базы.

Да, я стараюсь как можно внимательнее следить за этим.

Я не следую никаким другим стандартам кодирования.

Я следую PEP8, это отличный стиль программирования.