Главная » Статьи » Web-кодинг » Прочие статьи

Пробелы оставьте компьютеру

Как не заморачиваться стандартами форматирования кода

- Ужасно вредно не ездить на балы, когда ты этого заслуживаешь.

- Но у меня столько работы, крёстная!

- Сегодня друзья поработают за тебя. Грядки выполют зайцы, фасоль разберут мыши, кофе намелют кошки.

- А розы?

- А розы вырастут сами!

Евгений Шварц.. Золушка

На конференции РИТ++/2010, где я только что побывал, несколько раз поднимали вопрос о стандартах форматирования кода. Правда, говорили об этом вскользь и между делом. А мне кажется, что тема заслуживает отдельной беседы, чем я сейчас и займусь.

С тех пор, как появились языки программирования и прочего кодирования (вроде HTML и CSS), допускающие плюрализм в форматировании кода,- разработчики стали писать кто во что горазд.
Одному милее так:

Code
h1 {
color: #911;
}

Другому приятнее эдак:

Code
h1 {
color:#911;
    }

А третьему кажется, что ему лучше совсем наоборот:

Code
h1{color:#911;}

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

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

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

В этом есть определённый теоретический резон. Ну, представьте себе, если бы вдруг в популярных языках программирования арифметическое умножение можно было обозначать не только так: 2*2, но и, например, так: 2x2.
У обоих способов появилась бы куча приверженцев, кипели бы учёные споры и религиозные войны на тему «* vs x»...

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

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


Значит, перейдём ко второму способу борьбы с неодинаковостью, о котором я говорил.

Во многих софтверных фирмах и даже вольных опенсорсерских сообществах приняты подробные стандарты кодинга, лютости которых позавидовал бы Иван Грозный.
Делай отступ четырьмя пробелами, иначе тебя уволят. Помещай закрывающую скобку на отдельной строке, иначе твой код не примут в сообщество. Отделяй объявления друг от друга пустой строкой, иначе ай-яй-яй с прибабахом.

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

Знал я одного персонажа, который ввязывался в каждую разборку «пробелы против табуляции», брызгал слюной изо всех отверстий и орал несусветным голосом: «Табы! Только табы! В топку пробелы и всех, кто ими пользуется!» Кажется, даже у меня в блоге как-то выступил...

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

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


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

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

Может быть, тогда у них в замороченном мозгу наконец разомкнётся идиотская связка между «надо получить единообразный код» и «надо всех заставить писать одинаково».

Первое требование я целиком поддерживаю, а второе считаю идиотизмом на грани фашизма.

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


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


Главный принцип: пускай за форматированием кода следят не люди, а компьютеры.
Когда код открывается для просмотра или редактирования, сохраняется, пересылается или обрабатывается сторонней программой - сначала он автоматически пропускается через специальный скрипт, который приводит его к стилю, нужному в данной ситуации.

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

Откуда взять программу, которая будет выполнять все эти преобразования?

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


Ещё один, так сказать, use case.

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

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



Категория: Прочие статьи | Добавил: likbezz (31.05.2010)
Просмотров: 5495 | Теги: РИТ++, программист, пробелы, Табы, use case, стандарт, кода, форматирования
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]