Синдром лучшего стандарта кодирования

Разработчики часто склонны считать, что один стандарт кодирования лучше другого в плане читабельности. Некоторые думают, что добавление оператора break перед фигурными скобками повышает согласованность. Одним нравится стиль CamelCase, остальные его ненавидят.

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

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

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

Наш мозг функционирует таким образом, что всегда ищет знакомые структуры. Когда вы читаете фрагмент кода, ваш мозг находит шаблоны, существующие в вашей памяти, чтобы не перенапрягать мыслительную систему (напоминает какой-нибудь шаблон проектирования?)

Чтобы понять этот код:


    function doThisThing(PerssitedIdsArr){
      var i;
      for(i=0; i<PerssitedIdsArr.length; i++){
        console.log(PerssitedIdsArr[i]);
      }
    };


некоторым разработчикам понадобится на несколько миллисекунд меньше, чем потребует следующий код:


    do_this_thing = function(perssited_ids_arr)
    {
      for(var i in perssited_ids_arr)
        console.log(perssited_ids_arr[i]);
    };

Для остальных -- наоборот.


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

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

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

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

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

источник