сможете отличить Zen of Python от философии Лао-цзы? / Skillbox Media

#Тесты

• 9 ноя 2021

• 0

Попробуйте хакнуть наши вопросы и отделить философию Python от слов Лао-цзы.

Vkontakte

Twitter

Telegram

Скопировать ссылку

tesla / youtube

Тимур Тукаев

Фанат Free Software Foundation, использует Linux и недолюбливает Windows. Пишет истории про кодинг и программы на Python. Влюблён в Lisp, но пока что не умеет на нём программировать.

Лао-цзы — мудрый китаец, он написал «Дао дэ цзин». А Гвидо ван Россум — умный голландец, он создал Python. У этого языка программирования есть своя философия Zen of Python, текст которой выводит интерпретатор по команде import this. Говорят, её написал Тим Петерс.

Попробуйте определить, какая фраза взята из «Дао дэ цзин», а какая — из «Дзена Пайтона».

Клянусь, это Python!

А вот и нет, это сказал Лао-цзы.

Точно Лао-цзы!

Всё верно, это сказал Лао-цзы.

Узнаю старину Тима Петерса!

В десяточку — это «Дзен Пайтона». И вот расшифровка.

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

Явное лучше, чем неявное.
Объявляйте типы переменных, присваивайте функциям и переменным понятные имена — в общем, не заставляйте людей думать.

Простое лучше сложного. Сложное лучше, чем запутанное.
Построить что-либо можно с помощью простых или сложных методов. Написать to-do list можно из простых блоков, но для ИИ понадобятся сложные элементы. Простота — это хорошо, но у неё есть ограничения.

Это же Лао. Нихао, дядюшка!

Возможно, Лао-цзы тоже говорил так, но до нас его слова не дошли 🙂 Это «Дзен Пайтона». И вот расшифровка.

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

Явное лучше, чем неявное.
Объявляйте типы переменных, присваивайте функциям и переменным понятные имена — в общем, не заставляйте людей думать.

Простое лучше сложного. Сложное лучше, чем запутанное.
Построить что-либо можно с помощью простых или сложных методов. Написать to-do list можно из простых блоков, но для ИИ понадобятся сложные элементы. Простота — это хорошо, но у неё есть ограничения.

От этих слов пальцы так и тянутся закодить продвинутый AI!

Точно! 

Плоское лучше, чем вложенное.
Программисты любят выстраивать иерархии — модуль внутри другого модуля и так далее. В итоге получается какая-то бюрократия. Подключать субсубсубсубсубмодуль food. grain.corn.bread.white.fried.bun — это явно чересчур. Желаем всем, кто плодит сущности без необходимости, делать заказы в кафе по таким же алгоритмам 🙂

Разрежённое лучше, чем плотное.
Запихивать кучу полезной работы в одну строку — идея не очень. Сделайте несколько понятных строк, не заставляйте коллег проклинать вас.

Джеки Чан говорил что-то подобное, это Лао-цзы!

SyntaxError: invalid syntax. Это «Дзен Пайтона».

Плоское лучше, чем вложенное.
Программисты любят выстраивать иерархии — модуль внутри другого модуля и так далее. В итоге получается какая-то бюрократия. Подключать субсубсубсубсубмодуль food.grain.corn.bread.white.fried.bun — это явно чересчур. Желаем всем, кто плодит сущности без необходимости, делать заказы в кафе по таким же алгоритмам 🙂

Разрежённое лучше, чем плотное.
Запихивать кучу полезной работы в одну строку — идея не очень. Сделайте несколько понятных строк, не заставляйте коллег проклинать вас.

Хм… В моём коде на Python предыдущее и последующее точно следовали друг за другом…

А вот и нет — это древнекитайская философия.

О прекрасная и мудрая «Дао дэ цзин!

Великий китайский файервол аплодирует вам!

Типичный Python! Хотя я и замолчал бы пару своих ошибок.

Все верно, это «Дзен Пайтона».

Ошибки никогда не должны замалчиваться. Если они не замалчиваются явно.
Лучше, чтобы программа явно выдавала сообщение об ошибках: даже если они кажутся нестрашными прямо сейчас, со временем могут привести к серьёзным проблемам. И тогда будет трудно понять, что стало причиной сбоя. Но скрыть ошибку сознательно — это нормально, если вы убедились, что всё ок.

Да будет проклят тот из мандаринов, кто смеет замалчивать ошибки!

Поднебесная скорбит — мудреца не интересуют мирские ошибки.

Ошибки никогда не должны замалчиваться. Если они не замалчиваются явно.
Лучше, чтобы программа явно выдавала сообщение об ошибках: даже если они кажутся нестрашными прямо сейчас, со временем могут привести к серьёзным проблемам. И тогда будет трудно понять, что стало причиной сбоя. Но скрыть ошибку сознательно — это нормально, если вы убедились, что всё ок.

print («Это Python, ребята»)

Д6 — убит! Это и правда Python.

Перед лицом неопределённости отбрось искушение угадать.
Если код не работает, на то есть причина. И вместо слепого перебора всех методов, которые когда-то сработали, лучше использовать критическое мышление и внимательно проанализировать ситуацию. Ах да, включить-выключить пробовали?

Прекрасный слог, достойный рассказывать о непостижимом Дао!

Сакура плачет,
Бросая цветы на дорогу.
Даже японцы в курсе.

Это Python. Так уж вышло. 

Перед лицом неопределённости отбрось искушение угадать.
Если код не работает, на то есть причина. И вместо слепого перебора всех методов, которые когда-то сработали, лучше использовать критическое мышление и внимательно проанализировать ситуацию. Ах да, включить-выключить пробовали?

100% Python — он же используется для интернета вещей, а значит, программисты борются с вещами!

Оно, конечно, верно и для Python-программиста, но всё-таки это Лао-цзы.

Древние китайцы — мудрые ребята.

Оно, конечно, верно и для Python-программиста, но всё-таки это Лао-цзы.

Так и веет программистской логикой.

Лао-цзы загадочно улыбается, восседая на драконе…

Пустота, Восток, буддисты и всё такое.

Лао Цзы одобрительно улыбается, восседая на драконе…

Так это ж Python!

Ты познал тайны Дао! А надо было «Дзен Пайтона» 🙂

Весьма глубокомысленно — это Лао-цзы.

Ты познал тайны Дао!

Очень практично, это Python.

Тим Петерс шлёт привет!

Сейчас лучше, чем никогда. Хотя никогда зачастую лучше, чем прямо сейчас.
Начни делать прямо сейчас, иначе ничего так и не сделаешь. Но иногда лучше вообще не начинать, если планируешь писать код на скорую руку: глючная и неудобная программа — так себе решение.

Не, это точно Лао-цзы!

Где-то в мире заплакал один Тим Петерс. Это Python.

Сейчас лучше, чем никогда. Хотя никогда зачастую лучше, чем прямо сейчас.
Начни делать прямо сейчас, иначе ничего так и не сделаешь. Но иногда лучше вообще не начинать, если планируешь писать код на скорую руку: глючная и неудобная программа — так себе решение.

Говорят, Python достиг ясности в синтаксисе. Я за него.

Python достиг ясности в синтаксисе, но это Лао-цзы 🙂

А я за Лао-цзы и «Дао дэ цзин».

Всё правильно, это Лао-цзы.

Опять практичность — это точно Python!

Дзен в твоём сердце. Слушай его музыку!

Особые случаи не настолько особые, чтобы нарушать правила. При этом практичность важнее безупречности.
Best practices, правила и тому подобное — это хорошо и полезно, но не надо следовать им слепо. Иначе получится бюрократический код. Это про опыт. Пишите много кода, практикуйтесь и найдите золотую середину между правилами и практичностью. Так вы постигнете Дао. То есть дзен… Ой, да ну их!

Древние китайцы любят туманные слова вроде «безупречность».

А вот и нет — это «Дзен Пайтона»

Особые случаи не настолько особые, чтобы нарушать правила. При этом практичность важнее безупречности.
Best practices, правила и тому подобное — это хорошо и полезно, но не надо следовать им слепо. Иначе получится бюрократический код. Это про опыт. Пишите много кода, практикуйтесь и найдите золотую середину между правилами и практичностью. Так вы постигнете Дао. То есть дзен… Ой, да ну их!

Словом «это» начинался легендарный «Летающий цирк Монти Пайтона». Наверняка это Python!

Есть один и только один способ правильно ответить на этот вопрос — это он =)

Должен существовать один и желательно только один очевидный способ сделать это.
Это дружеский подкол в сторону другого языка программирования — Perl. Его девиз: «Есть больше одного способа сделать это». Но много способов сделать одно и то же затрудняет чтение и написание кода. Поди-ка разберись! Кстати, у этого пункта есть шутливое продолжение: «Хотя этот способ поначалу может быть не очевиден, если вы не голландец». Это намёк на создателя языка Гвидо ван Россума. Он как раз голландец.

Такого тумана мог напустить только Лао-цзы.

Этот ответ похож на совершенный, но нет =)

Должен существовать один и желательно только один очевидный способ сделать это.
Это дружеский подкол в сторону другого языка программирования — Perl. Его девиз: «Есть больше одного способа сделать это». Но много способов сделать одно и то же затрудняет чтение и написание кода. Поди-ка разберись! Кстати, у этого пункта есть шутливое продолжение: «Хотя этот способ поначалу может быть не очевиден, если вы не голландец». Это намёк на создателя языка Гвидо ван Россума. Он как раз голландец.

Я Python определяю с закрытыми глазами!

А с открытыми глазами получается чуть хуже 🙂

Ну ведь совершеннейший Лао-цзы!

Бинго! Конечно, это Лао-цзы.

Ну тут уже всё понятно, это Python

Это правильный ответ!

Пространства имён — отличная штука! Будем делать их больше!
Пространства имён — как папки на компьютере. Если вы попробуете положить два файла с одинаковым названием python.exe в одну папку — ничего не выйдет, а если в разные — всё получится. Пространства имён помогают разделять переменные и функции с одинаковым названием. Но помните про принцип «Плоское лучше, чем вложенное», используйте пространства имён только там, где они действительно необходимы.

Всё равно хочу, чтобы это был Лао-цзы!

И это неправильный ответ!

Пространства имён — отличная штука! Будем делать их больше!
Пространства имён — как папки на компьютере. Если вы попробуете положить два файла с названием python.exe в одну папку — ничего не выйдет, а если в разные — всё получится. Пространства имён помогают разделять переменные и функции с одинаковыми названиями. Но помните про принцип «Плоское лучше, чем вложенное», используйте пространства имён только там, где они действительно необходимы.

Junior

Похоже, древняя китайская философия тебе по вкусу. Значит, ты с удовольствием изучишь новую прекрасную философию — «Дзен Пайтона». Давай к нам на курс «Python-разработчик», мы всё покажем и расскажем.

Middle

Очень хороший результат! Только что в каком-то пространстве имён один Тим Петерс прослезился от умиления. А тебе, похоже, нужен хардкор — так получи его на курсе «Fullstack-разработчик на Python».

Senior

Привет, Гвидо! Решил поразвлечься на пенсии и хакнуть несколько тестов о Python? Ну тогда гоу к нам в Skillbox, на курс «Python-фреймворк Django». Мы сумеем тебя удивить!

* Решением суда запрещена «деятельность компании Meta Platforms Inc. по реализации продуктов — социальных сетей Facebook* и Instagram* на территории Российской Федерации по основаниям осуществления экстремистской деятельности».

Vkontakte

Twitter

Telegram

Скопировать ссылку

Понравилась статья?

Да

Философия Python . Изучаем Python [Программирование игр, визуализация данных, веб-приложения]

Долгое время язык программирования Perl был краеугольным камнем интернет-программирования. На первых порах функционирование многих интерактивных сайтов было основано на сценариях Perl. В то время сообщество Perl руководствовалось девизом: «Это можно сделать несколькими способами». Какое-то время разработчикам нравился такой подход, потому что гибкость, присущая языку, позволяла решать многие задачи разными способами. Подобный подход был допустим при работе над собственными проектами, но со временем стало ясно, что чрезмерная гибкость усложняет долгосрочное сопровождение крупных проектов. Было слишком трудно, утомительно и долго разбираться в коде и пытаться понять, что же думал другой разработчик при решении сложной задачи.

Опытные программисты Python рекомендуют избегать лишних сложностей и применять простые решения там, где это возможно. Философия сообщества Python выражена в очерке Тима Питерса «The Zen of Python». Чтобы просмотреть этот краткий набор принципов написания хорошего кода Python, достаточно ввести команду import this в интерпретаторе. Я не стану воспроизводить все принципы, но приведу несколько строк, чтобы вы поняли, почему они важны для вас как для начинающего программиста Python.

>>> import this

The Zen of Python, by Tim Peters

• Красивое лучше, чем уродливое.

Программисты Python считают, что код может быть красивым и элегантным. В программировании люди занимаются решением задач. Программисты всегда ценили хорошо спроектированные, эффективные и даже красивые решения. Со временем вы больше узнаете о Python, начнете писать больше кода, и когда-нибудь ваш коллега посмотрит на экран вашего компьютера и скажет: «Ого, какой красивый код!»

• Простое лучше, чем сложное.

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

• Сложное лучше, чем запутанное.

Реальность создает свои сложности; иногда простое решение задачи невозможно. В таком случае используйте самое простое решение, которое работает.

• Удобочитаемость имеет значение.

Даже если ваш код сложен, он должен нормально читаться. Работая над проектом, требующим написания сложного кода, постарайтесь написать содержательные комментарии для этого кода.

• Должен существовать один — и желательно только один — очевидный способ сделать это.

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

• Сейчас лучше, чем никогда.

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

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

Упражнения

2-11. Дзен Python: введите команду import this в терминальном сеансе Python и просмотрите другие принципы.

Дзен Python: руководство по принципам проектирования Python | Вишал Шарма

Пишем чистый и красивый код!

Пишите чистый код с помощью Python

Питонист однажды написал 20 афоризмов о том, как можно написать красивый и чистый код с помощью Python. Эти афоризмы, ставшие известными как «Дзен Python», взорвали разработчиков Python. Тим Питерс написал эти BDFL (Benevolent Dictator For Life, прозвище создателя Python Гвидо ван Россум) 20 руководящих принципов для разработки Python, но последний афоризм был оставлен для заполнения ван Россумом.0005

На сегодняшний день существует 19 афоризмов, поскольку Россум сказала, что последний афоризм — это «какая-то странная шутка Тима Питерса». Но что означают эти афоризмы? Давайте взломаем это!

Дзен Питона

Красивое лучше безобразного.
Явное лучше, чем неявное.
Простое лучше сложного.
Сложность лучше сложности.
Flat лучше, чем вложенный.
Разреженный лучше, чем плотный.
Учитывается читабельность.
Особые случаи не настолько особенные, чтобы нарушать правила.
Хотя практичность важнее чистоты.
Ошибки никогда не должны проходить молча.
Если явно не отключено.
Перед лицом двусмысленности откажитесь от искушения угадать.
Должен быть один — и желательно только один — очевидный способ сделать это.
Хотя поначалу это может быть неочевидно, если только вы не голландец.
Лучше сейчас, чем никогда.
Хотя часто никогда лучше, чем *прямо* сейчас.
Если реализацию трудно объяснить, это плохая идея.
Если реализацию легко объяснить, это может быть хорошей идеей.
Пространства имен — это отличная идея — давайте сделаем больше таких!

Вы можете открыть «Пасхальное яйцо» в своей Python IDE, набрав:

import this

Красивое лучше, чем уродливое код и его запуск — не единственная работа, чтобы сделать. Python известен своей удобочитаемостью и простотой. Так зачем вмешиваться? Написание чистого и читаемого кода — это искусство, которое ценят другие программисты и позволяют им понять каждый бит.

 def collatz(num): 
 if num%2 == 0: 
 return num//2 
 else: 
 return 3 * num + 1 
 number = input("Введите число:") 
 while number != 1: 
 number = collatz(int(number)) 
 print(number) 
 

В приведенном выше коде нет необходимости добавлять «else». В данный момент это кажется ненужным. В противном случае, чтобы сделать его лучше и чище, вы можете сделать что-то вроде:

 def collatz(num): 
 if num%2 == 0: 
 return num//2 
 return 3 * num + 1 
 

Явное лучше неявного

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

Простое лучше сложного

Зачем создавать сложный код, если можно создать более простой.

 def recursion_reverse(s): 
 if(len(s)==1): 
 return s 
 else: 
 return recursion_reverse(s[1:]) + s[0] 
 original_string = "ABC" 
 print("Reversed String : ", recursion_reverse(original_string)) 
 

Вы можете сделать это всего за две строки кода тоже.

 my_string = «ABCD» 
 reversed_string = my_string[::-1] 

Сложное лучше сложного

Приведенный выше афоризм утверждает, что простое лучше сложного. И теперь этот говорит: «Сложное лучше, чем сложное». Это становится запутанным! Для решения сложной проблемы может потребоваться сложная техника, но она не должна быть сложной.

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

Flat лучше, чем вложенный

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

Теперь доступ к другому подпакету из baz будет выглядеть так:

 from spam.foo.baz импортировать яйца 

Вложенность и иерархия добавляют не организации, а бюрократии!

Разреженный лучше, чем плотный

Иногда мы стремимся сделать все в одной строке кода. Вы можете получить правильный вывод. Но как насчет читабельности? Может ли кто-нибудь понять это, не заглядывая в него долго?

 print('\n'.join("%i bytes = %i битов, которые имеют %i возможных значений." % (j, j * 8, 256 ** j - 1) для j в 
 (1 << я для я в диапазоне (8)))) 

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

Читабельность подсчитывается

Вы заходите в StackOverflow каждый раз, когда застреваете в своем коде? Итак, на какой код вы смотрите? Читаемый один или сложный кусок!

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

Особые случаи не являются настолько особыми, чтобы нарушать правила

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

Хотя практичность превосходит чистоту

Вопреки приведенному выше афоризму «Особые случаи не настолько особенны, чтобы нарушать правила», этот афоризм предполагает, что может быть исключение из данного набора правил. Ключевое слово здесь «могут».

Ошибки никогда не должны проходить молча

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

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

Если явно не заглушить

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

Перед лицом двусмысленности откажитесь от искушения угадать

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

Должен быть один — и желательно только один — очевидный способ сделать это

В программировании на Perl есть поговорка: «Есть больше одного способа сделать это!» Использование трех-четырех кодов для выполнения одного и того же действия похоже на палку о двух концах. Мало того, что на его написание уходит время, так еще и каждый товарищ должен уметь читать ваши 3–4 метода без каких-либо проблем. Гибкость в этой практике не стоит праздновать.

Хотя поначалу это может быть неочевидно, если вы не голландец

Отсылая к Гвидо ван Россуму, создателю Python, этот афоризм говорит о том, что правило языка будет нелегко выучить или вспомнить, если только вы не станете создателем кода. Шутка, относящаяся к BDFL!

Сейчас лучше, чем никогда

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

Хотя никогда лучше, чем *прямо* сейчас

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

Если реализацию трудно объяснить, это плохая идея

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

Если реализацию легко объяснить, это может быть хорошей идеей

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

Пространства имен — это отличная идея — давайте сделаем больше таких!

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

 a = 2 
 print('id(a) =', id(a)) 
 a = a+1 
 print('id(a) =', id(a)) 
 
 print('id( 3) =', id(3)) 
 

Выведено:

 id(a) = 9302208 
 id(a) = 9302240 
 id(3) = 9302240 

Python организует переменные под капотом просто невероятный. Вот почему пространства имен — это круто!

Заключение

Python великолепен! Вот почему миллионы разработчиков используют его, пишут в нем код, анализируют с его помощью данные и строят с его помощью модели. Руководящие принципы, сделанные для него, только мотивируют программистов писать простой, читаемый и чистый код. В следующий раз, когда вы сядете за программирование, попробуйте следовать этим рекомендациям.

Ссылки

1. PEP 20 — Zen of Python

Приятного программирования!

Python Zen — философия кода Python и лучшие практики

Написание чистого и элегантного Python — это искусство, необходимое для создания качественного кода. К счастью, основатели Python оставили ряд руководящих принципов, которые помогут разработчикам в этом начинании: Zen of Python .

Что такое дзен Python?

Ваш первый шаг на пути к пифоническому просветлению — найти Дзен . Используя ваш любимый интерпретатор Python, просто введите:

В поисках вашего Python Zen

И вот, Появляется Zen !

Сам Python Zen!

Написанный в 1999 году одним из основных разработчиков Python, Тимом Питерсом, Zen of Python представляет собой список из 19 афоризмов, излагающих философию дизайна Python . 5 лет спустя он стал таким стандартом среди разработчиков, что PEP 20 (Python Enhancement Proposal) включил его в официальную литературу по Python, создав пасхальное яйцо, показанное выше.

Давайте взглянем на философию дзен и на то, как ее можно применить к нашей практике развития!

Ясность

Написать чистый код означает написать код, который легко воспринять, понять или интерпретировать .

Если вы разработчик, скорее всего, вы будете тратить более 8 часов в день на просмотр кода. Это подводит меня к первой строке Python Zen:

Красивое лучше, чем безобразное. (1)

И, конечно же, седьмое:

Читабельность имеет значение. (7)

На практике несколько инструментов и стандартов могут помочь следовать этим принципам, начиная с соглашения об именовании (PEP 8) до средства форматирования кода (черный).

При оценке своего кода важно поставить себя на место несведущего (но свободно говорящего на Python) человека , поскольку «код читается намного чаще, чем пишется » (Гвидо Ван Россум, доброжелательный диктатор Python для жизнь).

Явность

Написание явного кода означает написание кода, который не оставляет места для сомнений. Две части Дзэн детализируют эту концепцию:

Явное лучше, чем неявное. (2)
Должен быть один - и желательно только один - очевидный способ сделать это. (12)

Например, первый практический способ сделать ваш код более явным — использовать подсказки типов (представленные в PEP 484) и автоматические средства проверки типов (mypy).

Создание явных типов переменных Python с помощью подсказок типа

Эта концепция еще больше применима к обработке ошибок . Если вы когда-либо отлаживали код, вы знаете, что без сомнения на причину/местоположение вашей ошибки сэкономит вам много времени и усилий. Так говорит Дзен!

Ошибки никогда не должны проходить молча.
Если явно не отключено. (10-11)

Модульность

Модульность — это идея разделения вашего кода на компонентов , которые можно разделить и объединить, чтобы обеспечить большую гибкость и независимость.

Простое лучше сложного. Комплекс лучше сложного. (3-4)

Разница между сложным и сложным здесь существенна:

• сложный код трудно понять, поскольку он включает в себя большое количество различных, но связанных объектов.
• A c сложный код трудно понять сам по себе.

Главный вывод: если вы пишете что-то сложное, разбейте его на более простые части. Даже если ваш код окажется сложным, каждую маленькую часть будет легче обнаружить. Отслеживание хирургического времени в Python, отладка и модульное тестирование проекта Pyspark с Pytest!

Прагматизм

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

Разработчики часто должны быть прагматичными в поиске баланса между лучшим способом и самым быстрым способом достижения цели.

This entry was posted in Популярное