Как написать худший возможный Python-код

Иногда проще показать, как не надо, чем объяснять, как надо.  

Вот список «правил», которые помогут вам гарантированно испортить любой Python-проект.

1. 🔒 Используйте непонятные имена переменных  

Называйте переменные x, y, a, thing. Абстракция — залог путаницы.

def f(x, y, z=None):

    a = x * 2

    b = y + a if z else y – a

    c = [i for i in range(a) if i % 2]

    return sum(c) + b

2.🧠 Пихайте максимум логики в одну строку

Сложные тернарные выражения и вложенные list comprehension — всё в одной строке.

result = [x if x > 0 else (y if y < 0 else z) for x in data if x or y and not z]

3.⚠️ Используйте eval() и exec()

Это медленно, небезопасно и глупо — но зато эффектно.

eval(“d[‘” + key + “‘]”)

4.🔁 Переиспользуйте переменные с разными типами

Пусть одна переменная будет и строкой, и числом, и списком — динамическая типизация же!

value = “42”

value = int(value)

value = [value] * value

5.🌍 Используйте глобальные переменные

Изменяйте состояние приложения откуда угодно. Особенно изнутри функций.

counter = 0

def increment():

    global counter

    counter += 1

6.🔮 Используйте магические числа и строки

Без пояснений. Пусть коллеги гадают, почему именно 42 или “xyz”.

if user.role == “xyz” and user.level > 42:

    access_granted()

7.📏 Игнорируйте стиль и отступы

Никаких PEP8, никаких правил. Пиши, как хочешь.

def foo():print(“start”)

 if True:

  print(“yes”)

   else:

    print(“no”)

8.🧱 Копируйте код из Stack Overflow, не вникая

Ctrl+C — это тоже разработка.

def complex_logic(x):

    return (lambda y: (lambda z: z**2)(y + 1))(x)

9.🧩 Придумывайте абстракции без надобности

Вместо простой функции — классы, фабрики и стратегии.

class HandlerFactory:

    def get_handler(self):

        class Handler:

            def handle(self, x): return x

        return Handler()

10. 💤 Добавляйте мёртвый код

Никогда не удаляй — вдруг пригодится. И пусть он грузится в каждый запуск.

def legacy_feature():

    print(“This feature is deprecated”)

    return

# нигде не вызывается

11.🔀 Не пишите документацию

Комментарии только мешают. Кто захочет — разберётся.

def a(x): return x+1

12.🧪 Пиши без тестов

Если код работает — зачем его проверять?

# Просто запускай и смотри глазами

process_user(data)

13. 🤖 Не используй AI и автодополнение

Только ручной кодинг, без подсказок. Ошибки — путь мастера.

🧠 Заключение

Все эти советы — примеры того, как не стоит писать код.

Если вы узнали себя — пора остановиться. Ведь Python задуман как язык, где важна читаемость, простота и явность.

“Beautiful is better than ugly.

Explicit is better than implicit.

Readability counts.”

— The Zen of Python

Поделиться:

Один комментарий

  1. Ребята AI использовать можно и нужно (в разумных пределах и с перепроверкой) по п.13, но автодополнение это просто вопрос удобства и привычки. Ну т.е. одно дело разрешать за тебя дописать слово в Notepad++ и другое надеяться на условный платный PyCharm, который может строить целые типовые конструкции. Вы должны понимать как и почему работает код в любом его месте и пока ты сам всё прописываешь успеваешь 10 раз обдумать правильную ли функцию взял, нельзя ли сделать лучше или просто по-другому. Да, в таком случае иногда переписываешь по 10 раз, оптимизируешь какие-то кривые решения, но пусть это дольше, ошибок на моей практике выходит меньше. Хотя полагаю дело вкуса и тем для кого программирование это не хобби, когда просто интересно сделать что-то, а полноценная работа… ну наверное они не могут позволить себе терять ни секунды времени)
    А так п.2 наше всё!)))

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *