Десять невысказанных правил, которые вы должны соблюдать в своем коде Python!

Вступление

Python - один из самых простых языков программирования, доступных в настоящее время для изучения. Более того, Python также является невероятным инструментом, который действительно зарекомендовал себя как в машинном обучении, так и в написании сценариев. Однако из-за простоты доступа к Python и того, что так много людей ежедневно погружается в демографию Python, каждому программисту на Python может быть трудно последовательно следовать рекомендациям Python Enhancement Proposal 8 (PEP8). Некоторые ошибки могут быть относительно простыми, но часто при работе в довольно большой команде может быть трудно сохранить согласованность кода без использования PEP8.

Хотя многие из этих правил не обязательно могут быть «невысказанными», многие из них, как правило, замалчиваются всякий раз, когда в разговор включается PEP8. Усовершенствование вашего кода для максимального соответствия PEP8 может быть разницей между получением работы или игнорированием, поэтому я думаю, что очень важно держать в памяти свежее руководство по стилю PEP8 для Python.

Отступ

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

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

Самая большая причина, по которой я использую отступы и отказываюсь использовать пробелы, заключается в том, что я считаю, что пока вы последовательны, это не имеет значения. В дополнение к этому, большинство IDE, включая Atom, PyCharm, Genie и почти наверняка множество других, фактически используют автоматический отступ для кода Pythonic с отступом табуляции, а не с четырьмя пробелами.

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

Комментарии к пробелам

Хотя я могу не согласиться с идеей принуждения программистов использовать четыре пробела вместо отступа, начало комментария без добавления пробела - одна из моих самых больших неприятностей в коде Pythonic. Рассмотрим этот пример:

#This
#is
#painful
#to
#type

Пожалуйста. Не делайте этого.

Вместо этого вы должны добавить пробел после разделителя комментариев, например:

# This
# is
# not
# painful
# :)

Добавление одного пробела меняет мир, и пример без пробелов выглядит гораздо уродливее. Кроме того, он не соответствует PEP8 и затруднит просмотр и чтение ваших комментариев. Хотя это может беспокоить меня больше, чем многих других разработчиков, я определенно видел, как это раздражало и других программистов.

Имена, которых следует избегать

Еще одно правило PEP8, которое часто признают немногие разработчики, - это имена, которых следует избегать любой ценой. Есть два имени, которых следует избегать, как бубонная чума, в любом виде программирования в целом. Это относится к переменным, функциям, классам и структурам и обязательно должно соблюдаться. Никогда не называйте переменную заглавной I или O. Причина, по которой следует избегать этой ошибки, заключается в том, что во многих шрифтах, включая общесистемные шрифты, I и O неотличимы от чисел 1 и 0. Даже если проблема со шрифтом присутствует. , обычно не рекомендуется вводить в заблуждение использование этих двух букв в качестве имен переменных. Например, верхний регистр I также может быть нижним регистром L. В общем, важно называть ваши переменные соответствующим образом и стараться избегать однобуквенных схем именования, когда они не нужны, поскольку может быть довольно сложно отслеживать переменные с символами назначается им наугад. Отличным примером исключения из этого правила являются статистические вычисления, где часто буквы типа n или буквы греческого алфавита имеют фактическое значение, полученное из статистики.

Имена также должны быть совместимы с ACII. Это важно, потому что не все системы будут поддерживать UTF-8 и другие кодировки, что может вызвать проблемы у других людей, просматривающих ваш код.

Явный код

Хотя всевозможные трюки вуду можно проделывать на Python на досуге, важно помнить, что более явный код - лучший код.

Не делайте этого:

def examp(*args):
    x, y = args
    return dict(**locals())

Вместо этого сделайте это:

def examp(x, y):
    return {'x': x, 'y': y}

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

Распаковка

Если вам известна длина списка или кортежа, вы можете присвоить имена его элементам с помощью распаковки. Распаковка, по сути, является той же концепцией, что и выталкивание, когда dim удаляются из повторяемого списка или кортежа и присваиваются соответствующие значения. Отличный пример этого - использование enumerate ().

lst = ["Cheese","Spaghetti"]
for index, item in enumerate(lst):
    print(index,item)
1 Cheese
2 Spaghetti

Заключение

Хотя часто PEP8 можно упустить из виду и код все равно будет работать, как ожидалось, важно, чтобы код Pythonic был стандартизирован и читабелен. Хотя есть определенные правила, с которыми многие могут не согласиться, эти правила все же следует соблюдать при работе с большими командами, особенно на уровне предприятия. Стандартизация синтаксиса упрощает программирование для всех, кто работает с вашим кодом.