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

Шпаргалка по пандам

Шпаргалка по командам Git

50 лучших вопросов на собеседовании по SQL

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

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

Совет 3: функции должны быть небольшими
Функция предназначена для повторного использования. И чем больше становится функция, тем меньше вероятность ее повторного использования. Это также коррелирует с тем, почему функция должна делать только одно. Если он будет делать только что-то одно, велика вероятность, что оно будет небольшим.

Совет 4: Принципы открытости и закрытости
Принцип открытости-закрытости (OCP) гласит, что класс, метод или функция должны быть открыты для расширения, но не для модификации. Это означает, что любой определенный класс, метод или функцию можно легко повторно использовать или расширить для нескольких экземпляров без изменения его кода.
Это не соответствует OCP, потому что всякий раз, когда появляется новая страна, нам нужно будет написать новый оператор if, чтобы дополнить ее. Сейчас это может показаться простым, но представьте, что нам нужно принять во внимание 100 или более стран. Как это будет выглядеть?

Совет 5: любой ценой избегайте комментариев
Комментарии имеют свойство быть ложно правдивыми. Они отвлекают внимание читателя от того, что на самом деле делает код, к тому, что говорит кто-то другой.

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

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

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

Совет 6: избегайте магических чисел
Магическое число — это жестко закодированное значение, которое может измениться на более позднем этапе, но поэтому его может быть сложно обновить.

Например, предположим, что у вас есть страница, на которой отображаются последние 50 заказов на обзорной странице «Ваши заказы». 50 — это магическое число здесь, потому что оно не установлено стандартом или соглашением, это число, которое вы придумали по причинам, изложенным в спецификации.

Теперь у вас есть 50 в разных местах — ваш SQL-скрипт (ВЫБЕРИТЕ TOP 50 * FROM заказы), ваш веб-сайт (ваши последние 50 заказов), ваш логин для заказа (для (i = 0; i

Совет 7: избегайте глубокой вложенности
Ограничьте уровни вложенности внутри циклов, условий или функций, чтобы улучшить читаемость.

Совет 8: избегайте жестких путей кодирования
Воздержитесь от жесткого кодирования путей к файлам или URL-адресов; вместо этого используйте файлы конфигурации или переменные среды.

Совет 9: Классы должны быть небольшими
Ага! Классы должны быть как можно меньшими. Точно так же, как функции.

Единственная разница состоит в том, что в функциях размер определяется количеством строк в этой функции, а в классах — количеством обязанностей в этом классе.

Обычно имя класса отражает виды обязанностей, которые он может нести, но если имя двусмысленно или слишком общее, скорее всего, мы возлагаем на него слишком много ответственности.

Это возвращает нас к SRP (принципу единой ответственности), который гласит, что у класса должна быть только одна причина — одна ответственность — для изменений.

Совет 10: избегайте сложных троичных выражений
Воздержитесь от использования слишком сложных троичных выражений; отдайте предпочтение читабельности краткости, чтобы сделать код более понятным.