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

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

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

Распространенное заблуждение по поводу неинициализированных переменных заключается в том, что они приводят к краху программы, так что несколько неинициализированных переменных быстро обнаруживаются простым тестированием. На самом деле программы с неинициализированными переменными могут безукоризненно работать годами, если биты в памяти соответствуют требованиям программы. Позже вызов с другим контекстом, перекомпиляция или какие-то изменения в другой части программы могут привести к последствиям разной степени тяжести — от необъяснимого поведения до периодического аварийного завершения программы.

Пример 1. Использование инициализирующего значения по умолчанию или оператора

для снижения степени смешивания потока данных и потока управления.

Варианты, отмеченные как лучшие, не имеют промежутка между определением и инициализацией.

Пример 2. Замена сложных вычислений вызовом функции. Иногда вычисление значения происходит таким образом, что лучше инкапсулировать его в функции (см. рекомендацию 11).

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

(см. рекомендации 77 и 78). Если вы уверены, что массивы всегда будут рассматриваться как строки в стиле С с завершающим нулевым символом, то такого немедленного присваивания будет достаточно:

Более безопасная инициализация заполняет все элементы массива нулевыми значениями:

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

Входные буферы и данные, описанные как

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

[Dewhurst03] §48 • [Stroustrup00] §4.9.5, §6.3

Краткость — сестра таланта. Чересчур длинные функции и чрезмерно вложенные блоки кода зачастую препятствуют реализации принципа "одна функция — одна задача" (см. рекомендацию 5), и обычно эта проблема решается лучшим разделением задачи на отдельные части.