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

И наконец, не пытайтесь заставлять использовать устаревшие правила (см. примеры 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()
 {
  // ...
 }

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

Пример 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
// приводит к выводу компилятором предупреждений, о
// безвредности которых нам доподлинно известно, когда
// разработчики сделают новую версию, которая не будет
// вызывать предупреждений, мы удалим из этого файла