[Devel] Кодинг-стайл для Python

[Evgeny Sinelnikov]

30 сентября 2010 г. 12:03 пользователь Devaev Maxim
<mdevaev на etersoft.ru> написал:
>> Нет. Ты кого разработчиками называешь? Вот Гугловым вроде как пробелы
>> удобны. Разработчикам питона тоже.
> Вот не надо гугловых разработчиков примешивать. Они не сторонники четырех
> пробелов, у них используется два и чихать они хотели на PEP-8. Думаю, что
> гугл рассматривал исключение из кодинг-стайла ради совместимости со
> стандартом питона и уверен, что они рассмотрели те проблемы, которые назвал
> ты. Судя по тому, что два пробела так и осталось, эти проблемы они сочли
> несущественными в сравнении с единообразием кода и удобством написания
> алгоритмов с большим уровнем вложенности.

Тем не менее, они оставили пробелы.

> Тогда почему мы не можем использовать табы, которые, по сути, как два
> пробела в гугле, только настраиваемые?
>

Потому, что при переносе кода бывают проблемы. Не я это придумал. Это
сказано во всех описаниях по этому вопросу:
http://www.secnetix.de/olli/Python/block_indentation.hawk
 "Furthermore, it can be a good idea to avoid tabs alltogether,
because the semantics of tabs are not very well-defined in the
сomputer world, and they can be displayed completely differently on
different types of systems and editors. Also, tabs often get destroyed
or wrongly converted during copy&paste operations."

В PEP-8 сказано так:
 http://www.python.org/dev/peps/pep-0008/
 "For new projects, spaces-only are strongly recommended over tabs.
Most editors have features that make this easy to do."

Разработчики языка Python говорят:
 "Для новых проектов, строго рекомендуется использовать только пробелы
вместо табов. Большинство редакторов имеют возможности сдлеать это
просто."

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

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

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

А кому придётся перенастраивать редактор по сравнению с общепринятыми
настройками? Ты говоришь, что всем. Я отвечаю, что всем это не удобно.

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

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


>
>> Ты ничего не объяснял. Ты ты пытался сослаться на, то что табы
>> придуманы их нужно использовать.
> Кроме этого, есть неиллюзорное удобство написания/чтения кода, примеры
> других компаний с их стандартами и краткую историю появления четырех
> пробелов. Ты же по прежнему опираешься на PEP и аргумент, что так пишут
> стандартные либы. Здесь я опять привожу пример с glib и Линусом. Тот факт,
> что в C можно использовать любые отступы еще не дает программистам право
> разводить в коде помойку. И если ты счекаутишь код ядра, ты не найдешь там
> ни одного пробельного отступа. Вопрос: почему проект с двумя миллионами
> строк кода не столкнулся с теми проблемами, про которые ты говоришь? Ответ:
> потому, что есть единообразный стиль, которому все следуют и приводят код к
> нему. И не надо мне говорить, что питон не воспримет код с разными
> отступами: он выдаст ошибку, которую можно исправить за несколько секунд.
> Итого, в репозитории всегда будет нормальный код с нормальными отступами.
>

И всё это имеет смысл только для Питона. И glibc или ядро приводить в
пример не надо.

>> А я не хочу бороться с "атавизмами", которые являются стандартами.
> Тут можно вспомнить винду, которая является атафизмом и фактическим
> стандартом во многих компаниях и странах.
>

Это что ещё за маргинальные предрассудки?

Вопрос только про питон. Каков стандарт для питона в большинстве
компаний? Правильно, пробелы.

Позиция борьбы "за чистоту" (типа Holy War: Windows vs Linux) не может
и не должна определять политику компании. Суть введения стиля
кодирования - уменьшить издержки, а не увеличить. При этом удобства
замедляющие работу пренебрегаются правилами её ускоряющими.

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


>> Ну, вот... У тебя значит удобства всеобщие (ты только поясния в чём
>> они), а проблемы у меня значит надуманные.
> В том, что табы можно подстроить под себя, в отличие от пробелов и
> воспринимать код так, как удобно конкретному разработчику.
>

Где эти "конкретные" разработчики, которым так важно увидеть шесть
пробелов на таб, вместо четырёх, без которых они код не смогут
прочесть?

Эта возможность "подстроить под себя" число таобов на пробел нужна
очень редко. Если задать политику, то не нужна вовсе. Это разумный
компромисс следования общепринятым стандартам.


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

Всё как-то решаемо. Но вариант с пробелами для питона позволяет решать
всего меньше.

-- 
Sin (Sinelnikov Evgeny)