is_реклам:

пошук, категорії та ін. показати ▼

The Zen of Python

The Zen of Python
автор опубліковано

Python (пайсон, пайтон, пiтон) – високорівнева мова програмування загального призначення з акцентом на виробництво розробника і читабельність коду. Синтаксис ядра Python мінімалістичний. В той же час стандартна бібліотека включає великий об’єм корисних функцій.

Про Python можна говорити багато, ще більше можна сперечатися.

Однією з найбільш цікавих характеристик мови є те, що вона має свою філософію. Філософію Python кожна людина зрозуміє по-своєму, а для програміста вона підкаже основні концепції написання коду цією мовою. Багато в чому я погоджуюсь з цією філософією, хоча не маю великого досвіду роботи на Python.

The Zen of Python

  • Beautiful is better than ugly. – Гарне краще ніж гидке.
  • Explicit is better than implicit. – Явне краще ніж неявне.
  • Simple is better than complex. – Просте краще ніж складне.
  • Complex is better than complicated. – Складне краще ніж заплутане.
  • Flat is better than nested. – Пласке краще ніж вкладене.
  • Sparse is better than dense. – Розріджене краще ніж густе.
  • Readability counts. – Читабельність має значення.
  • Special cases aren't special enough to break the rules. – Особливі випадки не настільки особливі, щоб порушувати правила.
  • Although practicality beats purity. – Хоча практичність перемагає прагнення до чистоти. Errors should never pass silently. – Помилки ніколи не мають замовчуватися.
  • Unless explicitly silenced. – Якщо на замовчуються явно.
  • In the face of ambiguity, refuse the temptation to guess. – Зустрівши двосмисленність, відкинь спокусу вгадати.
  • There should be one – and preferably only one – obvious way to do it. – Має існувати один, – і, бажано, тільки один – очевидний спосіб зробити це.
  • Although that way may not be obvious at first unless you're Dutch. – Хоча він спочатку може бути і не очевидним, якщо ви не голландець.
  • Now is better than never. – Зараз краще ніж ніколи.
  • Although never is often better than right now. – Хоча ніколи часто краще, ніж прямо зараз.
  • If the implementation is hard to explain, it's a bad idea. – Якщо реалізацію важко пояснити – ідея погана.
  • If the implementation is easy to explain, it may be a good idea. – Якщо реалізацію легко пояснити – ідея, можливо, хороша.
  • Namespaces are one honking great idea – let's do more of those! – Простори імен, дуже добра штука – треба робити їх якомога більшими.

Хочу підкреслити один пункт. Дуже мені до душі Readability counts. – Читабельність має значення. Однією із цікавих синтаксичних особливостей мови є виділення блоків коду за допомогою відступів (пробілів або табуляцій), тому в Python відсутні операторні дужки begin/end як в мові Delphi чи фігурні дужки як у C. Такий «трюк» дозволяє зменшити кількість рядків і символів в програмі і привчає до «гарного» стилю програмування. З іншої сторони, поведінка і навіть коректність програми може залежати від початкових пробілів в тексті. Деякі критики мови вважають таку поведінку неінтуїтивною та незручною.

Але не я. Приймаючи лабораторні у студентів, коли мішаються навчальні курси, завдання і мови програмування, стабільним залишається одне – нечитабельність коду. За ці роки мені уже починає здаватися, що я умію читати лише такі коди, і побачивши неоптимізований, можливо некоректний, але гарно вирівняний код – я просто його не зрозумію. Це є проблема. І студентів досить важко заставити вирівнювати код. Хоча б у блочних операторах. Це просто неможливо, їм здається що код «в рядочок» або «у стовпчик» пишеться, читається, і головне – працює набагато якісніше. Особливо винахідливі розміщають його у такі фігури, яким навіть назви немає. Вирівнювати код – для них це:

  • пуста трата часу
  • не полегшує пошук помилок
  • нічого не змінює в програмі
  • каприз викладача
  • сумніви щодо коректної роботи програми після оформлення коду
  • в будь-якому разі це робитиметься тільки після його написання

Так, це нічого, кажу я. Пишіть в рядочок, у стовпчик, кладіть міток побільше, не виділяйте пам’ять, використовуйте відкриті масиви і т.д. Я все одно прочитаю, навіть зрозумію. Але це я, я звикла до цього, і не маю сил із цим боротися. Була така мрія, щоб програми компілювалися тільки при наявності необхідних відступів. Аж от, Python, не відступивши отримуєш інший код. З моєї точки зору – це економія власних ресурсів. Блочний оператор саме так і має виглядати.

Проте, коли ці студенти потрапляють на роботу у справжній програмістський колектив, і там код має не тільки працювати тут і тепер, а читатися, правитися, тестуватися. Першим ділом – хоча б читатися. Легко, треба буде – будемо вирівнювати. Е ні, на погані звички ми підсідаємо змолоду. І не так легко заставити себе робити чи не роботи такі елеменатрні речі як пробіли через роки. І чи на це варто буде витрачати свій час на роботі?

схоже за тегами

Коментарів 5

  1. В основному згідний із філософією Python, але на рахунок відсутності крапки з комою, як признака закінчення команди, або використовувати вкладеність замість begin/end, думаю тут вони вже трішки перегнули палицю. Переглядаючи запис конференції РІТ(російські інтернет-технології)-2012, один із учасників у своему докладі підкреслив:

    ” Відсутність крапки з комою, як признака кінця команди є самим зневажливим, що може бути зроблено машиною по відношенню до девелопера”

    думаю багато хто із цим погодиться.

    p.s. Постараюсь в подальшому зробити пост на цю тематику, отож слідкуйте за оновленнями.

  2. В прекраснійшій мові програмування низького рівня Ассемблер, крапка з комою ставиться, і ставиться на початку рядка, і означає – коментар :)

  3. Микола пише: Відповіcти

    Дякую за пост. Матеріал дуже допоміг у підготовці презентації по Пітону.

    • Ангелина пише:

      Я дуже рада, що Вам сподобалось і стало це у нагоді. Підписуйтесь на наш блог і будьте першими у курсі новин!

Залишити коментар:

Яндекс цитирования UA TOP Bloggers