воскресенье, 1 мая 2011 г.

Tabs vs. Spaces

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

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

1. Отступ (Indentation). Использовать отступы нужно обязательно. Это улучшает восприятие и читабельность программы, а также визуально отражает вложенную структуру кода. Использовать для отступов можно как табуляцию, так и пробелы. Это дело вкуса.

ИМХО:
Если раньше я предпочитал табуляцию, то с недавнего времени твердо решил: для себя only spaces. Объясню почему:
  • Во-первых, большинство IDE по нажатию на "Tab" умеет добавлять пробелы. Например, так делает IntelliJ IDEA, с которой я уходить в обозримом будущем не собираюсь;
  • Во-вторых, практически во всех IDE по умолчанию используется моноширинный шрифт. Это значит что ширина всех символов одинакова (будь то пробел или буква "Ш"). Поэтому код, с форматированием пробелами произведенным в одном редакторе, будет идентично отображаться в другом;
  • В-третьих, использовать пробелы нужно, чтобы не сталкиваться с такими косяками как в GitHub (нельзя изменить размер табуляции);
  • В-четвертых (очень субъективный аргумент), в своем коде мне ни разу не приходилось использовать отступы с длиной отличной от 4 пробелов. И подозреваю, что эта возможность мне вряд ли когда-либо пригодится.

2. Выравнивание (Alignment). В коде нужно стараться избегать использования выравнивания, потому что это зло по определению. Такие украшательства чаще всего ни к чему хорошему не приводят, т.к. после малейшего рефакторинга все "произведение искусства" приходится реставрировать. Стив Макконнелл в данном случае дает одно простое правило: "Исправление одной строки не должно приводить к изменению нескольких других". Отдельно замечу, что даже если пришлось воспользоваться выравниванием, то делать его можно исключительно пробелами, иначе, при изменении размера табуляции, вся красота разъедется по экрану.

ИМХО:
Тут я немного засомневался, потому что не раз использовал "Smart Tabs" для  выравнивания, но теперь осознал и понял свои ошибки :). Дело в том, что "умная табуляция" не идеальна, т.к. в некоторых случаях табы ставятся в том месте где должны быть пробелы.

3. Работа в команде. Естественно если в команде есть Coding Style Guide, то забываем про пункты 1-2 и пишем код беспрекословно следуя соглашениям. Как говорится: "Кто тимлид того и тапки" (с) MihallicA.

ИМХО:
Однако если меня не связывает никаких ограничений, то я делаю так, как удобно лично мне.

4. Чужой код. Разные способы форматирования - это не повод к разжиганию holy wars. Важно понимать, что практически вся польза от использования какого-то конкретного стиля заключается в том, что в проекте используется этот и ТОЛЬКО ЭТОТ стиль. Добиться единства - вот для чего затеваются все эти споры.

ИМХО:
Если же мне в руки попадает чужой код, который при всем желании исправить нельзя, то я работаю с тем что есть и не обращаю внимания ни на какие предрассудки.

И вместо заключения, я хотел бы процитировать классика: "Действительно хорошие программисты должны непредвзято относится к привычным для них способам форматирования и признавать другие варианты, даже если при переходе к новым методам  возникает некоторый начальный дискомфорт." (с) Стив Макконнелл

Комментариев нет:

Отправить комментарий