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


145

В то время как я читал этот вопрос , самый популярный ответ цитировал дядю Боба по стандартам кодирования , но я был смущен этим советом:

  1. Не записывайте их, если можете этого избежать. Скорее пусть код будет способом, которым стандарты собраны.

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

Почему я не должен записывать стандарт кодирования?


47
Хм. Я пытаюсь представить, как это будет работать в большой многонациональной компании с сотнями разработчиков и базой кода, охватывающей десятилетия.
Мэтью Джеймс Бриггс

31
@MatthewJamesBriggs: он работает как минимум так же хорошо, как записанный стандарт, который игнорирует большинство разработчиков, или который имел другой контент в то время, когда код был написан изначально.
Док Браун

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

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

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

Ответы:


256

Есть несколько причин.

  1. Никто не читает документацию.
  2. Никто не следует документации, даже если они читают ее.
  3. Никто не обновляет документацию, даже если они читают ее и следуют ей.
  4. Написание списка практик гораздо менее эффективно, чем создание культуры.

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

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


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

31
У вас действительно нет стандартного документа, но вы просто кричите на людей в течение первых нескольких недель при каждой проверке кода? Похоже, что в основном вы ожидаете, что новички перепроектируют ваши руководства по стилю кодирования. Или это скорее гипотетическое «я думаю, это то, что он имел в виду»? Теперь, если речь идет об автоматических инструментах, обеспечивающих соблюдение этих правил - согласен, это важно. Но я не хочу кропотливо выяснять правила.
Воо

13
@ Voo, почему вы чувствуете, что вам нужно кричать во время проверки кода, если возникает проблема?
Яап

20
@ Яп Я думал, что гипербола была очевидна .. очевидно, нет. Не кричать на людей, а говорить им, что они должны вернуться и исправить все то, что они нарушили, потому что они не могли знать лучше.
Во

5
@ Voo: вам не нужно «перепроектировать руководства по стилю кодирования». Соглашения должны быть очевидны при взгляде на существующий код. Все, что не сразу бросается в глаза, либо необычно, либо даже не исправлено. Если есть действительно важные правила о том, что происходит редко, возможно, стоит обсудить это с новыми разработчиками, когда именно им приходится писать такой код. Общение невозможно переоценить.
Хольгер

112

Есть другая интерпретация. Я не верю, что это имел в виду дядя Боб, но это стоит рассмотреть.

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

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

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

Если это имеет значение, то определите строго, что именно вы хотите, и потерпите неудачу, если это не так.


6
На самом деле, я подозреваю, что что-то подобное было, по крайней мере, частью аргументации дяди Боба. Автоматизация стандартов кодирования идет вместе с автоматизированным тестированием как полезный способ улучшения качества, и я уверен, что Боб знает это ...
Жюль

10
Возможно, стоит упомянуть правило № 6: After the first few iterations, get the team together to decide.только с правилом № 3 кажется, что он выступает за отсутствие стандарта кодирования, но при рассмотрении всех правил вместе и, прежде всего, № 6, кажется, что он действительно говорит: «Не сначала установите стандарт кодирования. Позвольте ему развиваться органично, а через некоторое время сядьте со своей командой, чтобы выработать детали ». Который сильно отличается от «Не формализуйте свой стандарт кодирования» (который, похоже, является сутью многих ответов).
Шаз

Если вы прочтете пункты, я думаю, вы поймете, что это определенно не то, что он имел в виду, например, этот один должен вам кое-что сказать: 2. Пусть они будут специфичны для команды, а не для конкретной компании.
Билл К

Обратите внимание, что я отвечаю на вопрос «Почему бы мне не записать стандарт кодирования», а не «Что имел в виду дядя Боб». Это может противоречить названию вопроса, но не его духу.
Том Джонсон

Обратите внимание, что автоматизированная система форматирования кода, которая не содержит условного обозначения escape (где я могу отключить его для части кода), в какой-то момент почти наверняка станет вредоносной.
Якк

66

Люди упускают из виду реальную цель документа о стандартах кодирования, который заключается в разрешении споров .

Большинство решений в стандарте кодирования будут иметь очень незначительное влияние на удобочитаемость и производительность. Особенно, если вы принимаете «нормальный» стиль для языка, и разработчики языка начинают понимать, что это должно быть частью спецификации (например, Go).

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

Наличие письменного стандарта заканчивает спор. Менеджеры могут указывать на это и отражать недовольство документом. Вы можете поспорить с листком бумаги, но он вас не послушает.

(См. Также Тирания бесструктурности )


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

4
Гораздо важнее согласиться со стандартом, чем с фактическим содержанием стандарта. Вы можете привыкнуть к любому стилю, если будете работать с ним достаточно долго.
Марк Рэнсом

3
Спорить о мелочах это признак некомпетентности, ИМХО. Урегулирование конкретного спора не решит основную проблему.
Йорген Фог

1
Да, разрешение споров и сохранение незагрязненной истории изменений огромны, особенно когда в вашей команде работают разработчики OCD и не очень OCD. Однако я обнаружил, что письменные стандарты являются гораздо менее эффективными арбитрами, чем автоматизированные инструменты, такие как StyleCop, которые устанавливают закон, не делая его личным и не тратя время менеджеров.
Эрик Херст

12
«Спорить о тривиальности - это признак некомпетентности» - хотелось бы, чтобы это было правдой в разработке программного обеспечения ... Боюсь, что некоторые очень, очень компетентные (по крайней мере, технически) разработчики - именно те люди, которые больше всего любят спорить о тривиальности. Черт, это их национальный вид спорта. «Бесконечны аргументы магов» - Урсула Ле Гуин
Spike0xff

21

Потому что комментарии это ложь .

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

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

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

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

Наличие стандартов кода важно. Наличие документа, который диктует, кем они не являются.


22
Я действительно испытал многолетнюю кодовую базу с политикой «без комментариев»; хотя он поощряет очень длинные имена описательных методов, он абсолютно ужасен при захвате намерений, причин не делать что-либо, и нам это сходит с рук только тем, что один из авторов остается с нами.
pjc50

7
+1 «Наличие стандартов кода важно. Наличие документа, который определяет, кем они не являются». Ну и в сжатой форме.
Дэвид

4
@ pjc50 Я никогда не слышал, чтобы дядя Боб поощрял политику отсутствия комментариев. Он не учит, что вы никогда не должны комментировать. Он учит, что вам должно быть плохо, когда вы обнаружите, что должны сделать это, чтобы вас поняли. Некомментированный нечитаемый <комментируемый нечитаемый <читаемый код, который не нуждается в комментариях. Обратите внимание, что упомянутые вами комментарии полностью отделены от того, КАК работает код. Стандартные документы могут превратиться в контрольный список мертвых мозгов, который будет отмечен в обзоре кода. Важно не то, что вы получаете все свои тики. Это то, что люди за столом понимают ваш код.
candied_orange

3
«Новые программисты должны тратить время на просмотр кода, а не тратить дни на чтение документа, состоящего из нескольких глав». Понятия не имею, за какими руководствами по кодированию вы следуете, но руководство по стилю Google C ++ может быть легко прочитано менее чем за час, и его гораздо проще понять, чем необходимость перепроектировать предпочтительный стиль на основе существующего кода (что звучит для меня ужасно). То же самое верно для любого другого руководства по стилю, которое я когда-либо читал.
Воо

5
@CandiedOrange: Часто самые полезные комментарии - это те, которые описывают причину, по которой некоторые вещи не были выполнены [так как в отсутствие таких комментариев будущие программисты могут тратить время на попытки реализовать, а затем отказываться от кажущихся очевидными «улучшений», которые превращают быть неработоспособным. Если не сходить с ума от имен переменных, невозможно, чтобы даже самый блестяще читаемый код смог собрать эту информацию.
Суперкат

16

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

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

Почему я не должен записывать Стандарт кодирования?

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

НАПИШИТЕ ЭТО ВНИЗ . Однако я постараюсь объяснить мои причины ...

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

Однако формулировка дяди Боба не заставляет меня думать, что он говорит об этом.

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

  • В некоторых случаях письменные стандарты кодирования требуются по закону.
  • Я читаю документацию и уверен, что я не одинок. Члены команды могут со временем меняться, знания не могут быть в 5-10-летней базе кода или в головах членов команды. Организации должны увольнять людей, которые не следуют внутренним правилам.
  • Стандарты кодирования, как только они будут утверждены , не будут часто меняться, и если они это сделают, вы хотите знать об этом. Если стандарты изменились, то ваша документация (в коде) устарела, потому что весь ваш код не соответствует новому стандарту. Переформатирование / рефакторинг может быть медленным, но у вас всегда есть письменное авторитетное руководство.
  • Лучше прочитать 5-страничный документ, чем проверять 10 / 20K LOC, чтобы экстраполировать правило (которое вы можете неправильно понять, кстати), без сомнения об этом.
  • Ирония в том, что кто-то, кто написал много книг о принципах дизайна и стиле кодирования, предлагает вам не писать свои собственные правила, разве не лучше, если он бросит нас с некоторыми примерами кода? Нет, потому что в письменных руководствах говорится не только о том, что делать, но и о двух других вещах, которых не хватает в коде: что не следует делать и причины делать это или нет.

«Свободное самоорганизующееся программирование» хорошо для 16-летнего парня-ниндзя, но у организаций есть другие требования :

  • Качество кода должно быть предоставлено (и определено) на уровне компании - это не то, что может решить одна команда. Они могут даже не иметь навыков, чтобы решить, что лучше (например, сколько разработчиков имеют все необходимые навыки для проверки MISRA или даже просто понимают каждое правило?)
  • Участники могут перемещаться в разные команды: если все придерживаются одних и тех же стандартов кодирования, интеграция проходит гладко и менее подвержена ошибкам.
  • Если команда самоорганизуется, то со временем, когда члены команды меняются, стандарты будут развиваться - и тогда у вас будет огромная база кода, которая не соответствует действующим принятым стандартам .

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

Конечно, небольшая организация, в которой есть только одна команда, может позволить команде решить, какие стандарты следует принять, но затем она должна быть записана. Здесь, на Programmers.SE, вы можете прочитать посты Эрика Липперта: я полагаю, мы все согласны с тем, что он опытный разработчик, когда он работал в Microsoft, ему приходилось придерживаться их письменных рекомендаций (даже если некоторые правила могут быть неправильными , неприменимыми или бесполезными). ему.) Как насчет Джона Скита? Правила Google довольно строгие (и многие люди с ними не согласны), но он должен придерживаться таких правил. Это неуважительно к ним? Нет, они, вероятно, работали над определением и улучшением таких рекомендаций, компания не состоит из одного члена (или одной команды), и каждая команда не является островом .

Примеры

  • Вы решили не использовать множественное наследование и вложенные классы в C ++, потому что вы, члены команды , плохо понимаете это . Позже кто-то, желающий использовать множественное наследование, должен просмотреть весь 1M LOC, чтобы увидеть, использовалось ли оно когда-либо. Это плохо, потому что если проектные решения не задокументированы, вам нужно изучить всю кодовую базу, чтобы понять их. И даже тогда, если он не использовался, это потому, что он противоречит стандарту кодирования или это разрешено, но просто не было более ранних ситуаций, когда множественное наследование подходило?
  • В C # у вас были перегруженные методы для предоставления параметров по умолчанию, потому что ваша кодовая база началась, когда дополнительные параметры были недоступны в C #. Затем вы изменили и начали использовать их (рефакторинг старого кода, чтобы использовать их каждый раз, когда вам приходилось изменять такие функции). Еще позже вы решили, что необязательные параметры являются плохими, и вы начали избегать их использования. Какое правило ваш код говорит вам? Это плохо, потому что стандарт развивается, но кодовая база развивается медленнее, и если это ваша документация, то у вас проблемы.
  • Джон перешел из команды А в команду Б. Джон должен выучить новый стандарт; во время обучения он, вероятно, представит более тонкие ошибки (или, если повезет, просто займет много времени, чтобы понять существующий код и сделать проверку кода более длительной).
  • Команда A переходит на кодовую базу, ранее принадлежавшую команде B. У нее совершенно другие стандарты кодирования. Переписать? Адаптировать? Смешать? Все они одинаково плохи.

Дядя боб

Пусть они развиваются в течение первых нескольких итераций.

Правда, до тех пор, пока у вас нет стандарта и ваша организация не поставит вам задачу его создать .

Пусть они будут конкретными для команды, а не для конкретной компании.

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

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

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

Не издавайте закон о хорошем дизайне. (например, не говорите людям не использовать goto)

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

Убедитесь, что все знают, что стандарт касается общения, и ничего больше.

Мало того, что хороший стандарт касается качества, если вы не хотите иметь стандарт только для мелких деталей.

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

Смотрите первый пункт и не забывайте, что стандарт кодирования - это, как правило, процесс, который разрабатывался и совершенствовался долгими годами: несколько итераций, может быть, у начинающих разработчиков? В самом деле? Вы хотите положиться на память одного старшего (если есть) члена?

Три ноты:

  • На мой взгляд, недостатки в некоторых языках более серьезны, чем в других, например, в C ++ стандарт уровня компании еще более необходим, чем в Java.
  • Это рассуждение может не применяться полностью (а причины дяди Боба могут быть менее экстремальными ), если вы работаете в очень маленькой компании, где у вас всего одна небольшая команда.
  • Вы наняты (как команда), и вы будете работать в одиночку с одним новым проектом, тогда вы забудете его и продолжите. В этом случае вам может быть все равно (но ваш работодатель должен ...)

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

5
@gnat спасибо, мне не нужны голоса для пост-темы, не "Почему мистер X сделал Y?" не по теме в этом случае? Мы не знаем его причин, и он не объяснил их, не должен ли вопрос закрываться как не по теме? Как бы вы ответили на этот вопрос? Придумывать случайные причины или говорить, что предпосылка ошибочна?
Адриано Репетти

1
@AdrianoRepetti - Дядя Боб много объяснял на протяжении многих лет, поэтому разумно подумать, что кто-то может иметь некоторое представление о его мышлении, но вы правы, если прямое толкование дяди Боба требуется.
JeffO

3
@ Jeff Да, если вопрос о том, «почему он так думает», тогда ответ - просто предположение. Если вопрос "это правильно?" тогда мой личный ответ d *** абсолютно нет.
Адриано Репетти

1
«Когда он работал в Microsoft, он должен был придерживаться их письменных указаний», - держу пари, я это сделал. И, конечно, мы использовали FXCop и StyleCop, чтобы не допустить проверки некоторых плохих паттернов
Эрик Липперт,

12
  1. Чтобы быть полезным, стандарт кодирования не должен говорить о вопросах существа; только вопросы стиля. Следует указывать только те вещи, которые являются произвольными и неоднозначными. например, расположение фигурных скобок, глубина отступа, пробелы и табуляции, соглашения об именах и т. д.
  2. Проблемы стиля являются локальными, а не глобальными. Каждая команда должна принять свой особый стиль, соответствующий их задачам и их индивидуальности. Это делает стандарты простыми и легкими. Корпоративные стандарты перегружены всеми возможными соображениями, конфигурациями и исключениями.
  3. Внутри команды единственной причиной написания отдельного документа стиля кодирования является то, что код, созданный командой, не соответствует стандарту. В этом случае у вас нет стандарта. Чтобы быть эффективным, стандарт должен быть выражен самим кодом. И если это так, то нет необходимости в отдельном документе.
  4. В устаревших системах команды и стили меняются со временем. В этом нет ничего плохого. Старый код будет иметь более старый стиль. Более новый код будет иметь более новый стиль. Команда должна знать о стилях и их возрасте. Всякий раз, когда пишется новый код, он должен быть в новом стиле, независимо от того, где он находится в коде.

У меня есть несколько затруднений: 1) чтобы быть полезным, стандарт кодирования должен говорить не только о форматировании (вопрос о священных войнах, но легко понять код чтения), но и о конструкциях, которых следует избегать, о шаблонах кодирования (для предотвращения распространенных ошибок, нелегко понять язык). особенности) и вопросы безопасности. Это рекомендации по кодированию (более полезные, чем вопросы форматирования). 2) Исходя из предпосылки пункта 1, речь идет не о личности (но может быть о задачах ), вы можете иметь легкий корпоративный стандарт, это ваша собственная обязанность сделать его легким.
Адриано Репетти

3) Код может сказать вам, что делать, но он не может передать то, что вы не должны делать (если только вы не хотите изучать всю кодовую базу и даже в этом случае ... просто не пришлось использовать конструкцию X, или это нет-нет?) Еще одна важная вещь - рассуждение: почему бы и нет? а почему да? Со временем все может измениться, но как вы узнаете, действительны ли первоначальные предпосылки? 4) и когда вы новый член команды и пишете новый код ... изучаете ли вы кодовую базу того же возраста, чтобы сохранить этот стиль кодирования? На следующий день после того, как вы переходите к другому более новому компоненту и снова изучаете кодовую базу (фильтрация по дате создания?)
Адриано Репетти

Кстати, если вместо этого вы предлагаете не записывать только стили форматирования кода, тогда я могу согласиться (ну, на самом деле нет, но не с такими вескими причинами, кроме воспоминаний о бесконечных и бесполезных дискуссиях, которые неизбежно будут возникать каждый раз) и которые являются корпоративным руководством будет избегать раз и навсегда) однако вы должны дать понять, иначе люди будут толковать ваши слова слишком буквально (см. большинство ответов + комментарии здесь). Также этот пункт о «гото» немного вводит в заблуждение в этом смысле (ИМО)
Адриано Репетти

4

Почему я не должен записывать Стандарт кодирования?

Существует много причин для этого. Вот некоторые соображения:

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

  2. Когда проект будет отложен / отложен / и т.д. тогда те немногие люди, которые остаются, обычно не могут придерживаться (или, возможно, даже не читали) стандартов. Следующее, что вы знаете, все эти усилия по «поддержанию кода в чистоте» в любом случае были потрачены впустую.

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

Вы должны обязательно прочитать # 6:

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

Другими словами, когда пришло время начать проект, просто попробуйте какое-то время. Затем обсудите общие правила стандартов кодирования, которые использует текущая команда, и в основном следуйте им. Таким образом, вы максимизируете усилия по улучшению продукта, одновременно сводя к минимуму усилия, необходимые для написания, просмотра и документирования «синтаксического сахара», необходимого для получения исполняемого кода.

Очень немногие команды получают огромные преимущества от стандартов кодирования. Как правило, «читабельность» слишком расплывчата - и большинство разработчиков не очень выигрывают от точных правил пробелов, новых строк и т. Д., Но вы можете избежать постоянных раздражающих разработчиков, имея хотя бы несколько правил.


4

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


4

Во-первых, насколько я знаю, дядя Боб - человек Java, это очень важно для понимания того, что он говорит.

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

Java и C #, как и большинство современных языков, были определены так, чтобы у программиста было немного «простых» ловушек.

Однако когда я начал программировать, я использовал C (а позже C ++). В C вы можете написать код, как

if (a = 3);
{
   /* spend a long time debugging this */
}

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

if (3 = a)
{
   /* looks odd, but makes sense */
}

Компилятор выдает ошибку, и я легко изменить код на 3 == a. Аналогично, если стандарт кодирования не позволяет= использовать его внутри ifусловия или «пустого ifоператора», то для отслеживания этой ошибки можно использовать средство проверки кода как часть системы сборки.

Мои взгляды на стандарты кодирования сильно изменились, когда я отошел от C / C ++: раньше мне нравились стандарты кодирования, которые строго соблюдались, и много страниц. Теперь я думаю, что вам нужно всего лишь перечислить используемые инструменты и получить неофициальное соглашение между первоначальными членами команды по нескольким соглашениям об именах. Мы больше не живем в мире команд из более чем 30 разработчиков, пишущих приложения на C / C ++ ...

Есть причина, по которой мне никогда не нравился JScript, и я думаю, что TypeScript - это лучшее, что может случиться с веб-разработкой за многие годы. Я ожидаю, что разработчикам веб-интерфейса все еще нужны стандарты кодирования из-за дефектов в дизайне HTML / CSS / JScript и т. Д.


4
«Компилятор не выдаст ошибку» большинство современных компиляторов C и C ++ поддерживают сообщение о таком поведении с предупреждениями или, при желании, с полными ошибками. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB

2
«Во-первых, насколько я знаю, дядя Боб - человек Java, это очень важно для понимания того, что он говорит», это неправда, дядя Боб написал фантастические статьи на C ++ и определенно работал с C несколько лет.
Алессандро Теруцци

@JAB, К счастью, C / C ++ давно перестал использоваться для новых «бизнес-приложений» (например, до модемных компиляторов C / C ++) и теперь в основном используется только экспертами C / C ++, а не людьми, которые являются экспертами UI (MFC) например.
Ян

1
@AlessandroTeruzzi Модульный тест скажет вам, что метод не работает. Почему это терпит неудачу - это другое дело - даже если у вас были модульные тесты для метода с таким кодом, вам было бы очень трудно выяснить, что происходит не так. C ++ - один из самых капризных языков для отладки.
Т. Сар

2
Я думаю, что здесь есть недоразумение, вы не можете взять одно предложение UncleBob и проанализировать его изолированно. Если у вас есть программное обеспечение SOLID с небольшими классами, коротким методом и пуленепробиваемым охватом модульных тестов, стандарт кодирования является избыточным. Если у вас слабый код, огромный интерфейс, большие функции и мало охвата, стандарт кодирования может дать вам некоторое преимущество. Но UncleBob предлагает не иметь его, а распространять в устной форме с помощью совместной работы и рефакторинга (удалить слабый код из исходной базы). Сделайте ваш код живым стандартом кодирования.
Алессандро Теруцци

3

Наличие источника в качестве стандарта самодокументируемого кодирования подразумевает две вещи.

  1. Люди должны обращаться к базе кода и просматривать ее, чтобы стать опытными участниками. Это невероятно важно. Чтение руководств по кодированию - это пустая трата времени по сравнению с изучением основ кода.
  2. Он признает, что незначительные различия не важны. Важно договориться и понять основные принципы. Поддержание единого стиля не преследуется как искусство для искусства. Это не позволяет нетворческим придиркам раздражать и отвлекать других людей. Речь идет об облегчении общения через код в команде.

2

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

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


2

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

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

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

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

Сильно связаны: Эволюция в стандартах кодирования, как вы справляетесь с ними?


* Если люди не думают во время проверки кода при регистрации, ваши проблемы намного больше, чем просто стандарты кодирования.


1

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

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


0

Я думаю, что многие посты здесь путают стандарт кодирования с руководством по стилю .

Убедиться в том, что модули, разработанные разными командами, имеют одинаковые параметры компилятора, а ABI отличается от количества пробелов.

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

В частности , «не использовать XXX , поскольку он вызывает проблемы совместимости с YYY» не то , что вы бы увидеть, например , в следующих другой код, так как он не существует. Так что пусть код будет способом, которым собраны стандарты, может быть неясным или совершенно отсутствующим для некоторых видов стандартов, и, таким образом, это не может быть универсальным планом.

Нечто всепроникающее и важное, такое как неиспользование исключений или неиспользование newв некоторых встроенных системах, нельзя просто оставить общеизвестным знанием культуры, поскольку «информация является культурной (только)» противоречит основополагающим принципам производственных стандартов, таким как ISO-9000, что Разработчик этих встроенных систем использует (например, для автомобильных приложений). Эти важные вещи должны быть задокументированы, подписаны и официально оформлены.

Но это относится к кодированию , а не к стилю .

Изобретатели C и C ++ показывают, например, использование строчных имен, а не CaMelCaSe. Так почему же многие разработчики не следуют неявному примеру из фонда? Разве стиль стандартной библиотеки и канонических учебных материалов не должен быть подходящим для подражания?

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.