Может ли быть слишком много единообразия в стандартах кодирования?

12

Есть ли такая вещь, как слишком большая однородность? Там, где я работаю, у нас, конечно, есть стандарты, в том числе соглашения об именах, архитектуры, фреймворки для использования и т. Д. Однако в последнее время было много критических замечаний, которые я бы назвал более стильными.

Например, запись ifоператоров в несколько строк против одной строки с использованием ??оператора c # null-coalescing вместо, скажем == null, количества интервалов для отступов и т. Д.

Мне кажется, это начинает все больше увлекаться личным выбором стиля и не должно быть единообразным в команде или компании. То, что думает один человек, читается более ясно, другой не может. Есть ли какая-то ценность в этой «дополнительной» однородности?

programming-practices team coding-standards Gratzy
источник
2
Привет, Gratzy, Programmers.SE - это не доска объявлений ; Мы здесь, чтобы решить реальные проблемы, с которыми вы можете столкнуться. У вас есть реальная проблема, которую вы пытаетесь решить? Если да, можете ли вы перефразировать свой вопрос, чтобы ответы оставались конструктивными и исключали возможность стать предметом обсуждения?
1
@ Gratzy, говоря иначе, учитывая ситуацию, с которой вы лично сталкиваетесь, каковы критерии правильного ответа?
2
@Mark Trapp согласно FAQ это критерии для вопроса. Все субъективные вопросы должны быть конструктивными. Как мы это определяем? Конструктивные субъективные вопросы… 1. Вдохновите ответы, которые объясняют «почему» и «как». 2. склонны иметь длинные, а не короткие ответы. 3. иметь конструктивный, справедливый и беспристрастный тон. 4. пригласить поделиться опытом по поводу мнений. 5. настаивать на том, чтобы мнение было подтверждено фактами и ссылками. 6. это больше, чем просто бездумное социальное веселье. Я считаю, что мой вопрос охватывает как минимум первые 4
Gratzy
2
@Gratzy также из FAQ: «Вы должны задавать только практические, отвечающие на вопросы вопросы, основанные на реальных проблемах, с которыми вы сталкиваетесь. Болтливые, открытые вопросы уменьшают полезность нашего сайта и отталкивают другие вопросы с первой страницы».
2
@Mark Trapp Я уже сформулировал критерии приемлемого ответа, и да, как я уже сказал, это актуальная проблема, и, откровенно говоря, из-за интереса к вопросу и ответов, которые, я бы сказал, другие согласны.
Gratzy

Ответы:

16

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

Лучше всего просто установить базовый стиль для самых важных вещей (стандарты именования и заглавных букв, отступы, новые строки и размещение скобок и т. Д.), Установить рекомендации для менее важных вещей (если формат выписки, другие пробелы в скобках и т. Д.) , а потом не переживай за остальных.

Николь
источник
1
Я был там
+1, сказал, что я имел ввиду, но лучше!
FrustratedWithFormsDesigner
@Pierre, поэтому ты сейчас фрилансер? :)
Николь
не совсем, но я знакомлюсь с некоторыми одержимыми людьми по поводу руководящих принципов. Страшно, как это может быть экстремальным. Я думаю, что вы определили предел довольно хорошо.
7

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

В наши дни большинство IDE могут применять стили, поэтому при необходимости вы можете распространять (как часть исходного кода проекта) файл настроек IDE, в котором указан выбранный стиль кодирования, и пусть все установят его и используют его для форматирования кода, который они пишут. , Могу поспорить, что есть даже способы переформатировать / стилизовать код при регистрации (хотя мне еще не приходилось это исследовать).

FrustratedWithFormsDesigner
источник
Да, вы могли бы где-нибудь вставить скрипт для муравьев.
Майкл К
1
IntelliJ, по крайней мере, имеет возможность переформатировать код перед регистрацией.
Николь
3

Один случай чрезмерной однородности, который я видел, - это наличие единого стандарта, который применяется ко всем языкам программирования независимо от их соответствия:

  • Дестимулирование gotoдаже в таких языках , как C без try... catch.
  • Использование InitialCapsимен (как в Microsoft MFC и C #) в JavaScript, где находится стандартная библиотека initialLowerCase.
dan04
источник
2

Я не думаю, что есть такая вещь, как слишком много единообразия. Тем не менее, я часто нахожу это слишком СПЕЦИФИЧНОСТЬ в стандартах кодирования. Преимущества того, что все ставят открывающую скобку на отдельной строке, в лучшем случае сомнительны и не перевешивают время, затрачиваемое на споры или исправление косметических проблем в коде.

JohnFx
источник
2
@ Тунгано Я не могу не согласиться. Парадокс стандартов кодирования в том, что они того стоят, но о них не стоит спорить.
Чарльз Грант
3
Я не понимаю, как навязывание программисту определенного стиля поможет вам избежать этих аргументов. На самом деле, я бы сказал, что если программист адаптируется к стилю, который им не нравится, УЧИТЫВАЕТ эти аргументы или, по крайней мере, обиду.
JohnFx
1
@JohnFx, потому что большинство программистов поймут, что согласованность стиля вносит гораздо больший вклад в качество кода и удобство сопровождения, чем любой конкретный выбор стиля. По моему опыту, вы можете быстро подсчитать количество команд, посмотреть, что людям нравится и не нравится, и быстро прийти к общему мнению. Иногда у кого-то появляется своеобразный багабу, и вы его приспосабливаете, а потом они уступают чьему-то другому. Если я в течение пяти минут пытаюсь убедить команду в том, почему дело о верблюдах является злом, я просто сдаюсь и сдаюсь в качестве теста моей личной гибкости.
Чарльз И. Грант
1
Я бы сказал, что большинство программистов ДУМАЮ, что постоянство стиля вносит такой большой вклад, но на самом деле это не так. Кажется, что это должно, это раздражает смотреть на код, который не соответствует вашему стилю питомца, и прохождение блока кода, «очищающего его» для незначительных косметических проблем, является хорошим способом откладывать на потом. Слушай, я тоже был на этой победе, пока не понял, что сосредоточился на золочении, а не на результатах.
JohnFx
1
Я работаю с кодом из нашей немецкой команды, парой проектов OSS и некоторым древним кодом, который у нас есть, а также с нашими текущими материалами. Некоторые это C, некоторые C ++, некоторые C #. Поэтому мне все время приходится работать с несколькими разными стилями кода. Когда вы делаете это, вы понимаете, насколько мелочны правила стиля, которые закреплены в стандартах. Если я смогу переключиться с одного проекта на другой, я смогу справиться с кем-то, помещающим свои {} в разные места. Вот почему я думаю, что единственный стандарт, на который стоит обратить внимание, - это правило с одним правилом: «согласованность в каждом проекте».
gbjbaanb
2

У меня было бы 2 аргумента для единообразия:

  • Содействие коллективной собственности. То, что кто-то может пойти и отредактировать чужой код, не опасаясь, что чье-то «дитя» может пострадать от этого изменения. Этакий менталитет «Мы все вместе».

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

JB King
источник