Серия для разработчиков

Fast Python: 5 лучших практик для Pythonic Code

Часто студенты, изучающие компьютерные науки, заканчивают обучение, не зная лучших практик и стандартов программирования, используемых в индустрии программного обеспечения. Это приводит к дерьмовому коду и ужасным историям, что приводит к смущению и часто шуткам.

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

Один из ключевых выводов Гвидо заключается в том, что код читается гораздо чаще, чем пишется. Приведенные здесь рекомендации предназначены для улучшения читабельности кода и обеспечения его согласованности в широком спектре кода Python. Как говорится в PEP 20, «читабельность имеет значение».

Я собираюсь поделиться пятью простыми правилами написания кода на Python для продакшена.

Правильное использование пустых строк

Окружите определения функций и классов верхнего уровня двумя пустыми строками.

Определения методов внутри класса окружены одной пустой строкой.

Дополнительные пустые строки могут использоваться (экономно) для разделения групп связанных функций. Пустые строки могут быть опущены между кучей связанных однострочников (например, набор фиктивных реализаций).

Осторожно используйте пустые строки в функциях для обозначения логических разделов.

# Add two blank lines before each function or class definition
def myfunc(a,b):
 
 # Add a blank line before every if statement
 if a > b:
 print(“Hello World”)
 
 # Add a blank line before every return statement
 return a,b

Описательные стили именования

Существует множество различных стилей именования. Это помогает распознавать, какой стиль именования используется, независимо от того, для чего он используется.

Обычно различают следующие стили именования:

  • б (одна строчная буква)
  • B (одна заглавная буква)
  • нижний регистр
  • нижний_case_with_underscores
  • ВЕРХНИЙ РЕГИСТР
  • UPPER_CASE_WITH_UNDERSCORES
  • CapitalizedWords (или CapWords, или CamelCase — названы так из-за неровного вида букв). Это также иногда называют StudlyCaps. Примечание. При использовании акронимов в CapWords все буквы аббревиатуры должны быть заглавными. Таким образом, HTTPServerError лучше, чем HttpServerError.
  • MixedCase (отличается от CapitalizedWords начальной строчной буквой!)
    Capitalized_Words_With_Underscores (уродливо!)

Импорт

Импорт обычно должен быть в отдельных строках:

Правильный:

import os
import sys

Неправильный:

import sys, os

Хотя можно сказать так:

Правильный:

from subprocess import Popen, PIPE

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

Импорт должен быть сгруппирован в следующем порядке:

  • Импорт стандартных библиотек.
  • Связанный сторонний импорт.
  • Импорт локальных приложений/библиотек.

Предписывающие соглашения об именах

Имена глобальных переменных

(Будем надеяться, что эти переменные предназначены для использования только внутри одного модуля.) Соглашения примерно такие же, как и для функций.

Модули, предназначенные для использования через **from M import ** **, должны использовать механизм all, чтобы предотвратить экспорт глобальных переменных, или использовать старое соглашение о добавлении перед такими глобальными переменными символа подчеркивания (что вы можете сделать, чтобы указать, что эти глобальные переменные являются « модуль непубличный»).

Имена функций и переменных

Имена функций должны быть написаны строчными буквами, а слова должны быть разделены символом подчеркивания, если это необходимо для улучшения читаемости.

Имена переменных следуют тому же соглашению, что и имена функций.

MixedCase разрешен только в тех контекстах, где этот стиль уже преобладает (например, threading.py), чтобы сохранить обратную совместимость.

Аргументы функции и метода

Всегда используйте self в качестве первого аргумента методов экземпляра.

Всегда используйте cls в качестве первого аргумента методов класса.

Если имя аргумента функции конфликтует с зарезервированным ключевым словом, как правило, лучше добавить одиночное подчеркивание в конце, чем использовать аббревиатуру или искажение орфографии. Таким образом, classлучше, чем clss. (Возможно, лучше избегать таких конфликтов, используя синоним.)

СУХОЙ принцип

Принцип DRY или «Не повторяйся» — это практика разработки программного обеспечения, направленная на уменьшение повторения информации.

Принцип DRY, популяризированный в книге «Прагматичный программист», гласит, что «каждая часть знания должна иметь единственное, недвусмысленное, авторитетное представление в системе». Используя принцип, логика или алгоритмы, которые имеют определенную функциональность, должны появляться в приложении только один раз.