пятница, августа 03, 2007

К вопросу о "стандартах кодирования"

На форуме Artima Developer Spotlight появилась тема: "What's the Most Effective Code Style Policy?", посвящённая обсуждения "стандартов кодирования".

Немного о терминологии

На самом деле даже сам термин "coding policy" или "стандарты кодирования" многозначен. Разные авторы или компании вкладывают в него разные смыслы, в зависимости от которых область применения стандартов может быть существенно сужена или наоборот расширена.

Рассмотрим возможные смыслы термина:

  1. Стиль и синтаксис форматирования исходного кода программы
    • Расстановка скобок
    • Использование пробелов и пустых строк
    • Правила написания выражений (for, if, while и так далее)
    • Правила именования переменных
    • Правила объявления переменных
    • Правила написания комментариев
    • Правила использование отступов
  2. Иногда к содержанию первого пункта могут быть добавлены элементы "управления конфигурацией"
    • правила именования файлов
    • структура файлов проекта
    • правила использования системы контроля версий
    • стандартизация используемых средств разработки
  3. Иногда к стандартам кодирования могут также быть добавлены "best practices" того, как надо писать программы, в зависимости от определённого языка программирования, среды разработки, компании или специфики разрабатываемого продукта (типичным примером может служить требование "всегда создавать в классе виртуальный деструктор", для C++)
Конечно же, "стандарты кодирования" могут включать в себя содержимое и всех пунктов сразу, и какую-то их смесь, а также что-то что здесь не упомянуто.

Мой взгляд

Здесь я хочу ответить на вопрос, заданный в теме на форму Artima - "What's the Most Effective Code Style Policy?".

Обращаю внимание, что все дальнейшие рассуждения касаются "стандартов кодирования" в смысле (1) и оставляют аспекты (2) и (3) без внимания.

Основной необходимостью существования "стандартов кодирования" обычно называют (некоторые части процитированы по Code Conventions for Java Programming Language, они отмечены '*'):
  1. Необходимость работ над одним и тем же исходным файлом нескольким программистам
  2. Улучшение "понятности" исходного кода, что позволяет программистам более полно и быстро понять новый для них код (*)
  3. Необходимость сопровождения (исправления ошибок, внесения небольших исправлений) кода и тот факт что в большинстве случаев споровождение осуществляется не тем же человеком, который является исходным автором кода. (*)
  4. Программист, работающий над исходным кодом, который написан не в "любимом" или "привычном" стиле будет тратить на его исправление больше времени (аргумент Bill Venners из исходного сообщения в форуме).
Моё мнение состоит в том, что усилия на создание и поддержание "стандартов кодирования" в большинстве случаев существенно выше чем затраты на "понимание" или поддержку кода, написанного "в другом стиле". Я конечно не имею ввиду примеры из "Obfuscated C Code Contest" :-) В большинстве случаев, код написанный вменяемым программистом понятен другому вменяемому программисту, вне зависимости от того, как именно расставлены в нем фигурные скобки или именованы переменные. Единственной неприятностью могут быть различия в настройках отступов и табуляций/пробелов, при просмотре кода различными текстовыми редакторами, просмотрщиками и программами сравнения.

Поэтому в моей голове всегда существовал такой "стандарт кодирования":
  1. Единообразная настройка длины табуляции (tab length)
  2. Использование пробелов вместо табуляций
  3. При правке кода пользоваться тем стилем, который используется в этом коде
Вот собственно и все. А если Вы или Ваш коллега пишете код в стиле "Obfuscated C Code Contest", то подумайте может проблема должна быть решена не при помощи "стандартов кодирования", а как-нибудь по-другому?

17458907.195e50a0db7e7428ccd693c67f635406.1186161181.ba176d26a55281a16d8fd8b02a541ce8
17458907.48319b4763d4aa2700c0fda3363b9fab.1186391267.b8da257c7d1fa1c830df3b9f73d6fb72

4 комментария:

lrrr комментирует...

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

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

Формальные, написанные на бумаге гайдлайны тут нужны чтоб не возникали длительные бесполезные дискуссии на темы вроде "как нормальные люди называют переменные".

Анонимный комментирует...

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

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

1. При правке кода пользоваться тем стилем, который используется в этом коде
2. Использование пробелов вместо табуляций

alexandroid комментирует...

>> Моё мнение состоит в том, что усилия на создание и поддержание "стандартов кодирования" в большинстве случаев существенно выше чем затраты на "понимание" или поддержку кода, написанного "в другом стиле".

Какие усилия на поддержания стандартов кодирования вы имеете здесь ввиду? Если делать инспекции кода, то единожды поправленный код (приведенный к стандарту, если есть отклонения) сэкономит время десяткам разработчиков в будущем. В том числе и автору программы, который со временем забудет детали этого кода.

Ценность станарта, мне кажется, не столько в его "удачности", сколько в его единственности.

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

Lev Kurts комментирует...

2alex efros: Согласен с замечанием, действительно первый пункт избыточен.

2alexandroid: я имею ввиду усилия по "переформатированию", ссоры и споры по поводу того на какой строке ставить скобки и тому подобное.

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

Насчёт среды ... не совсем уверен, что это хорошо. Дело в том, что часто используются номера строк кода, которые "поедут", если например среда будет автоматом переносить скобки. Плюс непонятно как вести себя различным "diff" программам. Короче говоря тут подумать надо, особенно если все пользуются разными средами, diff-ами и так далее.