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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

if(true)
{
}

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

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

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

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

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

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

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

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

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

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

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