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

Пт Окт 1 02:04:22 MSD 2010

On Среда 29 сентября 2010, Evgeny Sinelnikov wrote:
...
> Я ещё раз хочу напомнить, что я против использования табов,
> вместо общепринятых 4- пробелов и готов ставить вето в этом
> плане. Обоснование вида, что "и табы тоже можно использовать"
> принять не могу, ибо "и пробелы тоже можно использовать". Это
> не аргумент.

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

К тому же Максим предлагает не столько удобный ему вариант, 
сколько возможный для него (другие будут плохо восприниматься). 
Это всё равно как обсуждать размер шрифта, который мы должны 
писать код. Люди могут иметь разные комфортные величины, и дело 
тут не в личных предпочтениях.

Я предлагаю сделать какие-то выводы на будущее.

Что до ситуации с Tab/пробел, то я бы (пройдя подобный этап 10 
лет назад) начал сейчас с другой стороны — с инструментов.

Хотя и было бы неплохо составить таблицу с аргументами за и 
против Tab, чтобы хоть было из чего выбирать.

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

К примеру, вот для Emacs подробно рассмотрели по каждому языку 
форматирование:
http://www.emacswiki.org/emacs/CategoryIndentation

Вторым шагом я бы видел исследование и документирование средств 
переформатирования кода (типа indent и astyle), со скриптовыми 
обвязками, для приведения проектов в чувство в случае 
необходимости. Эту работу я уже проводил много лет назад для C++, 
но не знаю, что осталось. Возможно, новые инструменты появились. 
Суть в том, чтобы настройки (astyle) соответствовали принятому 
policy (общему/для проекта).

Третий шаг — это техническое обеспечение сосуществования людей с 
разными взглядами в одном проекте, реализация подхода «чтобы 
каждому было удобно». Я вижу это в виде некого механизма для git 
(очередной транслятор :), который будет вынимать/публиковать код 
в нужном формате (выполняя преобразование наподобие того, как он 
это делает с концами строк). Это позволит установить единые 
требования, но в то же время оставить каждому возможность 
использовать удобный ему подход.

К сожалению, всё это достаточно далеко от сегодняшнего дня (хотя 
Линус, к пример, написал git за 2 недели). Но я бы хотел 
посмотреть на два варианта:
а) быстро принять решение, и меньше тратить времени на оформление 
кода;
б) доработать все необходимые средства, чтобы решить ситуацию 
технически.

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

Важным аргументом за пробелы является возможность защититься от 
человеческого фактора — пробелы невозможно использовать 
неправильным образом (где не надо - то есть не только для 
отступов блоков кода), а Tab'ы — можно.

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

http://en.wikipedia.org/wiki/Programming_style#Coding_conventions_for_languages

Это означает, что использование табов действительно всё больше 
удел маргиналов. При разработке модулей python однозначно 
рекомендовано использование пробелов.

Надо сказать, что большие проекты типа Linux kernel, LyX 
придерживаются табов. Думаю, в силу чисто исторических причин, и 
уж точно не по причине возможности изменения размера Tab.

К примеру, в http://www.kernel.org/doc/Documentation/CodingStyle
(судя по стилю, писал Линус :)) жёстко устанавливают отступ в 8 
позиций, причём с помощью Tab. При этом использование Tab и 
оформление отступов оставляет желать лучшего - все тексты 
рассчитаны на то, что Tab - 8 позиций, и смена этого приведёт к 
плачевному виду кода.

Большой минус у Tab также в том, что есть сложность в оформлении 
с его помощью перенесённых строк вида

call_func(arg1, arg2,
          arg3, arg4);

С Tab будет (ну не особо критичная) проблема по выравниванию 
(начало второй строки будет ездить относительно скобок в первой.

Редактор mcedit отображает табы как <---->, что препятствует их 
копированию.

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

Также я бы не рассматривал многие вопросы оформления в разрезе 
языка, а делал бы их общими для всех языков.

В копилку ещё ссылка о войне пробелов и табов:
http://www.jwz.org/doc/tabs-vs-spaces.html

-- 
С уважением,
Виталий Липатов, ALT Linux Team, Eternity Software Team
Россия, Санкт-Петербург. http://etersoft.ru
GNU! ALT Linux! WINE! LaTeX! LyX! http://freesource.info