Насколько важны правила форматирования кода? [закрыто]


18

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

Разве не важнее то, что ваш код читабелен, а не соответствует ли он предопределенному стандарту? Похоже, они больше похожи на ... рекомендации в любом случае.

Ответы:


12

Попросить всех на 100% придерживаться одного и того же стандартного руководства по форматированию кода - это все равно, что попросить всех сотрудничать отдельно в написании 100-страничной статьи с одинаковым стилем письма.

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

Я думаю, что вы затронули самые важные моменты:

  1. Это руководство
  2. читабельность

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

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

Итак, чтобы ответить на ваш вопрос: несколько важно, но это точно не конец света, если они этого не делают.


3
Особенно № 2: удобочитаемость. Иногда определенный фрагмент кода можно сделать более читабельным, отклоняясь от руководства.
Барт ван Хейкелом

Благодаря современным IDE вы можете приблизиться к 100%, если переформатируете код на основе шаблона при каждой операции сохранения. Затмение делает это довольно хорошо.
Маркус

1
@Markus это работает, пока кто-то не захочет использовать другую IDE или редактор. Я предпочитаю делать это заранее, чтобы дать разработчикам больше свободы.
Густав Карлссон

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

5

Что касается стандартов форматирования, я слежу за тем, что делают все остальные. Если они используют PascalCase для всего, то я использую PascalCase. Если они используют _camelCase, то я использую _camelCase. Почему? Потому что это ограничивает количество переформатирования, которое я делаю, и ограничивает то, что другие должны делать, чтобы он «хорошо выглядел». Стандарты форматирования обычно существуют для того, чтобы всем было проще.


5

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

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

Это никогда не было принято.

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

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


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

2
Это никогда не принималось - тадаа, и было заявление, которое я искал, просматривая ответы. В этом весь смысл: чем больше людей и чем выше сложность и произвольность правил, тем меньше вероятность того, что они когда-либо будут приняты даже большинством команды. Если это не предписано каким-либо образом, как это делают Visual Studio или язык Go, разработчики склонны следовать своему собственному мнению. Я почти 10 лет жду IDE, которая отделяет контент кода от стиля кода.
JensG

2

Если вы используете и IDE, которая делает это за вас (например, Visual Studio), пусть IDE сделает свое дело, и все, что вам покажется трудным, вы можете изменить, если вы все еще позволяете IDE делать свое дело или следующий человек, который автоматически форматирует, просто убьет его.

То, что наиболее читабельно для одного человека, будет не для всех людей.

Если вы не используете этот вид IDE, получите его. Даже думать об этом более 10 минут - пустая трата ресурсов ИМХО.


4
Я должен не согласиться. Я не нахожу ничего более раздражающего, чем IDE, которая сама меняет форматирование. Почему я должен позволять ему изменять мой код без моего согласия? Это отсекает приличную часть контроля, который мне нравится иметь над моей работой.
Дерекердманн

Билл, вы говорите о соглашениях об именовании методом перетаскивания, которые генерирует IDE, таких как TextBox01? Или вы имеете в виду плагин для Visual Studio, такой как Resharper?
Спонг

Дерек - да, это раздражает, но время, которое избавляет меня от необходимости обращать на это внимание, 90% времени стоит 10% времени, которое мне приходится бороться.
Билл

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

В одной команде может быть несколько IDE - например, Eclipse и IDEA для Java. Чтобы настроить форматирование кода в виде файлов конфигурации, потребовалось бы немного усилий, но оно того стоит.
talonx

1

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

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

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

Одним из руководств, которые я использую при разработке или обновлении наших форматов кодирования, являются Гештальт-принципы группировки - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

В качестве прямого результата / примера наше форматирование кода требует, чтобы любой код блока (if, switch и т. Д.) Имел открытую фигурную скобку на следующей строке, чтобы он соответствовал закрывающей фигурной скобке:

if(true)
{
}

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


After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.Это не потому, что ваш формат кода помог им увидеть ошибку. Это потому, что задача переформатирования кода заставила их внимательно посмотреть на код, который они только что просматривали ранее.
Брандин

1

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

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


0

Худшее, с чем я столкнулся до сих пор, - это отсутствие стандартов кодирования. И вам запрещено делать какой-то блок кода более читабельным, потому что он ломает инструменты сравнения ... Поскольку мы используем исправления для применения изменений (запрос на изменение / исправление ошибки -> исправление / изменение -> исправление -> исправление, примененное «доверенным» лицом -> коммит) вы можете получить довольно забавно выглядящий исходный код (с точки зрения читабельности). По крайней мере, у нас нет никого, использующего двухбуквенные переменные (-.

[rant] Самое смешное, что все согласны с тем, что нам нужно это изменить. Была даже пара попыток переформатирования (автоматизированных при фиксации), но из-за отсутствия единственного крошечного варианта форматирования биты - все это только что получилось. Взгляд ... [/ rant]


0

Рекомендации помогают улучшить качество кода:

  • с точки зрения автора: многие правила направлены на уменьшение количества ошибок. Например, правило, утверждающее, что конструкции if()или for(;;)должны сопровождаться блоком, а не единственной инструкцией, делает явным намерение исходного кодера и помогает следующим кодерам поддерживать это.

  • с точки зрения читателя: код, который следует согласованным рекомендациям, рассматривается более эффективно, чем код с различными стилями. Рецензент лучше знает с меньшими усилиями, где искать возможные ошибки.


0

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

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

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

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