Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация

• Название: Стандарты программирования на С++. 101 правило и рекомендация
• Автор: Герб Саттер
• Издательство: Издательский дом "Вильямс"
• Жанр: Программирование
• Год: 2005
• ISBN: 5-8459-0859-0

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

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

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

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

---

void using k_and_r_style() {

 // ...

}

void putting_each_brace_on_its_own_line()

{

 // ...

}

void or_putting_each_brace_on_its_own_line_indented()

 {

  // ...

 }

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

Пример 2. Пробелы или табуляция. В некоторых командах использование табуляции запрещено (например, [BoostLRG]) на том основании, что размер табуляции варьируется от редактора к редактору, а это приводит к тому, что отступы оказываются слишком малы или слишком велики. В других командах табуляции разрешены. Важно только быть последовательным. Если вы позволяете использовать табуляцию, убедитесь, что такое решение не будет мешать ясности кода и его удобочитаемости, если члены команды будут сопровождать код друг друга (см. руководство 6). Если использование табуляции не разрешено, позвольте редактору преобразовывать пробелы в табуляции при чтении исходного файла, чтобы программисты могли работать с ними в редакторе. Однако убедитесь, что при сохранении файла

Пример 3. Венгерская запись. Запись, при которой информация о типе включается в имя переменной, приносит пользу в языке программирования, небезопасном с точки зрения типов (особенно в С); возможна, хотя и не приносит никакой пользы (только недостатки) в объектно-ориентированных языках; и невозможна в обобщенном программировании. Таким образом, стандарт кодирования С++ не должен требовать использования венгерской записи, более того, может требовать её запрета.

Пример 4. Один вход, один выход (Single entry, single exit — "SESE"). Исторически некоторые стандарты кодирования требуют, чтобы каждая функция имела в точности один выход, что подразумевает одну инструкцию return. Такое требование является устаревшим в языках, поддерживающих исключения и деструкторы, так что функции обычно имеют несколько неявных выходов. Вместо этого стоит следовать стандарту наподобие рекомендации 5, которая требует от функций простоты и краткости, что делает их более простыми для понимания

Ссылки

[BoostLRG] • [Brooks95] §12 • [Constantine95] §29 • [Keffer95] p. 1 • [Kernighan99] §1.1, §1.3, §1.6-7 • [Lakos96] §1.4.1, §2.7 • [McConnell93] §9, §19 • [Stroustrup94] §4.2-3 • [Stroustrup00] §4.9.3, §6.4, §7.8, §С.1 [Sutter00] §6.1, §20 [SuttHysl01]

1. Компилируйте без замечаний при максимальном уровне предупреждений

Резюме

Следует серьезно относиться к предупреждениям компилятора и использовать максимальный уровень вывода предупреждений вашим компилятором. Компиляция должна выполняться без каких-либо предупреждений. Вы должны понимать все выдаваемые предупреждения и устранять их путем изменения кода, а не снижения уровня вывода предупреждений.

Обсуждение

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

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

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

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

Примеры

Пример 1. Заголовочный файл стороннего производителя. Библиотечный заголовочный файл, который вы не можете изменить, может содержать конструкцию, которая приводит к (вероятно, мелкому) предупреждению. В таком случае "заверните" этот файл в свой собственный, который будет включать исходный при помощи директивы #include и избирательно отключать для него конкретные предупреждения. В своем проекте вы будете использовать собственный заголовочный файл, а не исходный. Например (учтите — управление выводом предупреждений варьируется от компилятора к компилятору):

// Файл: myproj/my_lambda.h - "обертка" для lambda.hpp из

// библиотеки Boost. Всегда включайте именно этот файл и не

// используйте lambda.hpp непосредственно. Boost.Lambda

// приводит к выводу компилятором предупреждений, о

// безвредности которых нам доподлинно известно, когда

// разработчики сделают новую версию, которая не будет

// вызывать предупреждений, мы удалим из этого файла

// соответствующие директивы #pragma, но сам заголовочный

// файл останется.

//

#pragma warning(push) // Отключение предупреждений только

// для данного заголовочного файла

#pragma warning(disable:4512)

#pragma warning(disable:4180)

#include <boost/lambda/lambda.hpp>

#pragma warning(pop) // Восстанавливаем исходный уровень

// вывода предупреждений

Пример 2. "Неиспользуемый параметр функции". Убедитесь, что вы в самом деле сознательно не используете параметр функции (Например, это "заглушка" для будущего расширения или требуемая стандартом часть сигнатуры, которую ваш код не использует). Если этот параметр вам действительно не нужен, просто удалите его имя:

// ... внутри пользовательского распределителя подсказка не

// используется …

// Предупреждение: "неиспользуемый параметр 'localityHint'"

pointer allocate(size_type numObjects,

 const void *localityHint = 0) {

 return static_cast<pointer>(

  mallocShared(numObjects * sizeof(T)));

}

// новая версия: предупреждение устранено

pointer allocate(size_type numObjects,

 const void* /* localityHint */ = 0) {

 return static_cast<pointer>(

  mallocShared(numObjects * sizeof(T)));

}

Пример 3. "Переменная определена, но не используется". Убедитесь, что вы действительно не намерены обращаться к данной переменной (к таким предупреждениям часто приводят локальные объекты, следующие идиоме "выделение ресурса есть инициализация", см. рекомендацию 13). Если обращение к объекту действительно не требуется, часто можно заставить компилятор замолчать, включив "вычисление" самой переменной в качестве выражения (такое вычисление не влияет на скорость работы программы):

// Предупреждение: "переменная 'lock' определена, но не

// используется"

void Fun() {

 Lock lock;

 // ...

}

// новая версия: предупреждение не должно выводиться

void Fun() {

 Lock lock;

 lock;

 // ...

}

Пример 4. "Переменная может использоваться, не будучи инициализированной". Инициализируйте переменную (см. рекомендацию 19).

Пример 5. "Отсутствует return". Иногда компиляторы требуют наличия инструкции return несмотря на то, что поток управления не может достичь конца функции (например, при наличии бесконечного цикла, инструкции throw, других инструкций return). Такое предупреждение не стоит игнорировать, поскольку вы можете только думать, что управление не достигает конца функции. Например, конструкция switch, у которой нет выбора default, при внесении изменений в программу может привести к неприятностям, так что следует иметь выбор default, который просто выполняет assert(false) (см. также рекомендации 68 и 90):

// предупреждение: отсутствующий "return"

int Fun(Color C) {

 switch(C) {

 case Red: return 2;

 case Green: return 0;

 case Blue:

 case Black: return 1;

 }

}

// Новая версия: предупреждение устранено

int Fun(Color C) {

 switch(C) {

 case Red: return 2;

 case Green: return 0;

 case Blue:

 case Black: return 1;

 // Значение !"string" равно false:

 default: assert(!"should never get here!");

 return -1;

 }

}

Пример 6. "Несоответствие signed/unsigned". Обычно не возникает необходимость сравнивать или присваивать числа с разным типом знаковости. Измените типы сравниваемых переменных так, чтобы они соответствовали друг другу. В крайнем случае, воспользуйтесь явным преобразованием типов. (Компилятор все равно вставляет в код преобразование типов и предупреждает именно об этом, так что лучше сделать то же самостоятельно.)