Стандарты программирования на С++

0. Не мелочитесь, или Что не следует стандартизировать

Резюме

Скажем кратко: не мелочитесь.

Обсуждение

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

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

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

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

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

• Следует использовать непротиворечивые соглашения об именовании, не слишком мелочно регламентируя его. Имеется только два императивных требования по поводу именования: никогда не используйте имена, начинающиеся с подчеркивания или содержащие двойное подчеркивание, и всегда используйте для макросов только прописные буквы (ONLY_UPPERCASE_NAMES), при этом никогда не применяя в качестве имен макросов обычные слова или сокращения (включая распространенные параметры шаблонов, такие как T или U; запись #define T anything может привести к крупным неприятностям). В остальных случаях используйте непротиворечивые значимые имена и следуйте соглашениям, принятым для данного файла или модуля. (Если вы не можете сами разработать соглашение об именовании, попробуйте воспользоваться следующим: имена классов, функций и перечислений должны выглядеть как LikeThis, имена переменных — likeThis, имена закрытых членов-данных — likeThis_, и имена макросов — LIKE_THIS.)

• Не предписывайте стиль комментариев (кроме тех случаев, когда специальный инструментарий использует их для документирования), но пишите только нужные и полезные комментарии. Вместо комментариев пишите, где это возможно, код (см., например, руководство 16). Не пишите комментарии, которые просто повторяют код. Комментарии должны разъяснять использованный подход и обосновывать его.

И наконец, не пытайтесь заставлять использовать устаревшие правила (см. примеры 2 и 3), даже если они имеются в старых стандартах кодирования.

Примеры

Пример 1. Размещение фигурных скобок. Нет никакой разницы в плане удобочитаемости следующих фрагментов:

void using k_and_r_style() {

 // ...

}

void putting_each_brace_on_its_own_line()

{

 // ...

}

void or_putting_each_brace_on_its_own_line_indented()

 {

  // ...

 }

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