Привет, дорогой читатель, меня зовут Ксавье Жувено, и это вторая статья о Code Craft Пита Гудлиффа. Если хотите, можете посмотреть предыдущую статью про Защитное программирование, а книгу можно найти здесь.

Глава, которую мы рассмотрим сегодня, называется «Наилучшие планы — компоновка и представление исходного кода».

Что такое стандарт кодирования?

Если вы зайдете на Википедию, вы можете найти хорошее определение стандарта кодирования, например:

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

Автор Code Craft идет еще дальше, говоря, что целью стандарта кодирования является также предотвращение общих проблем и объединение команды разработчиков с помощью кодирования. соглашения.

Звучит круто, мы все хотим избежать проблем и работать в единой команде, но тогда вы можете задаться вопросом, что такое соглашение о написании кода? И как получить некоторые? 🤔

Не волнуйтесь, это то, что мы собираемся описать в этой статье 😉

Соглашение о кодировании

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

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

Возьмем этот пример C/C++.

if(condition == failure)
  log(error);
  exit(1);

Тут легко представить, что хотел сделать автор. Если условие было неудачным, то он хотел зарегистрировать ошибку и завершить программу. Но на самом деле программа будет вести себя иначе! В случае сбоя он зарегистрирует ошибку, но в любом случае завершит программу. Вот что понимает компилятор:

if(condition == failure){
  log(error);
}
exit(1);

А вот что хотел сделать автор:

if(condition == failure){
  log(error);
  exit(1);
}

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

Какой стандарт кодирования?

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

Действительно, вам не нужно создавать новый стандарт кодирования для вашей команды или компании с нуля, существует множество стандартов кодирования! Например, у вас есть стандарт Indian Hill или стандарт GNU Misra. Автор также упомянул некоторые соглашения о расположении брекетов, такие как стиль брекетов K&R и стиль Allman, или расширенный стиль брекетов. Все эти стандарты могут дать вам пример соглашений, которые вы можете включать или не включать в свои проекты.

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

Почему так много стандартов кодирования?

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

Мне очень нравится идея, что все дебаты между стандартами кодирования позволяют нам иметь лучшие стандарты, доступные для нас. 🙂 Даже некоторые «Священные войны» о том, какой стандарт, условность или язык лучше всего 😆

Как интегрировать стандарт кодирования в вашу команду?

В зависимости от вашего проекта может уже существовать стандарт.

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

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

Но, к счастью для нас, автор был достаточно любезен, чтобы дать нам стандарт для создания стандарта в вашей команде 😉 Вот семь правил этого стандарта:

  • Определите область действия стандарта. Слишком широкий, он будет содержать мусор, слишком узкий, он будет слишком ограничивающим для использования.
  • Привлекайте людей к созданию стандарта. Если люди вовлекаются на раннем этапе, они захотят реализовать это, поскольку это частично их работа.
  • Создать документ. Ваш стандарт должен быть доступен для людей, чтобы они могли сослаться на него, а также для того, чтобы новые люди могли учиться.
  • Включает рекомендации команды. Это будет поощрять всех, если есть вещи, которые они уже делают.
  • Сосредоточьтесь на главном. Например, избегайте священных войн о табах или пробелах.
  • Начните с малого и увеличивайте размер позже. Так усыновление будет намного проще.
  • Похвала за усыновление. Поощряйте, а не наказывайте тех, кто не придерживается стандарта.

Вывод

Важно иметь четко определенный стандарт.

Это помогает всем в команде объединиться против проблемы, а не сосредотачиваться на том, где поставить брекеты. Более того, если возможно, вам обязательно следует автоматизировать разметку кода, когда это возможно, чтобы избежать конфликтов и проверки кода по поводу форматирования. Вот две ссылки по форматированию: Форматирование Cpp, C, Javascript и прочего, Форматирование CMake.

Я надеюсь, что эта статья поможет вам немного больше полюбить стандарт кодирования и, возможно, заставит вас принять один или несколько в зависимости от ваших проектов 😉

Спасибо всем за прочтение этой статьи, и до моей следующей статьи, хорошего дня 😉

Первоначально опубликовано на http://10xlearner.com 15 января 2020 г.