Стандарты программирования на С++. 101 правило и рекомендация
Шрифт:
Лечение этой болезни очень простое — определяйте каждую переменную настолько локально, насколько можете, что обычно означает точку непосредственное перед ее первым использованием, когда у вас уже достаточно данных для корректной инициализации.
Иногда с точки зрения производительности может оказаться выгодным вынесение переменной за пределы цикла (см. рекомендацию 9).
Поскольку константы не являются частью состояния программы, данная рекомендация на них не распространяется (см. рекомендацию 17).
[Dewhurst03]
19. Всегда инициализируйте переменные
Неинициализированные переменные — распространенный источник ошибок в программах на С и С++. Избегайте их, выработав привычку очищать память перед ее использованием; инициализируйте переменные при их определении.
В традициях низкоуровневой эффективности С++ (как и С), от компилятора зачастую не требуется инициализация переменных, пока вы не сделаете это явно (например, локальные переменные, члены, опущенные в списке инициализации конструктора). Такие переменные надо инициализировать явно.
Имеется несколько причин, по которым переменная может остаться неинициализированной. Но ни одна из них не является достаточно серьезной для того, чтобы оправдать опасность неопределенного поведения.
Если вы используете процедурный язык (такой как Pascal, С, Fortran или Cobol), вы можете определить переменные отдельно от кода, их использующего, и присвоить им значения позже, когда эти переменные будут использоваться. Этот подход устарел и не рекомендуется для использования (см. рекомендацию 18).
Распространенное заблуждение по поводу неинициализированных переменных заключается в том, что они приводят к краху программы, так что несколько неинициализированных переменных быстро обнаруживаются простым тестированием. На самом деле программы с неинициализированными переменными могут безукоризненно работать годами, если биты в памяти соответствуют требованиям программы. Позже вызов с другим контекстом, перекомпиляция или какие-то изменения в другой части программы могут привести к последствиям разной степени тяжести — от необъяснимого поведения до периодического аварийного завершения программы.
Пример 1. Использование инициализирующего значения по умолчанию или оператора
Варианты, отмеченные как лучшие, не имеют промежутка между определением и инициализацией.
Пример 2. Замена сложных вычислений вызовом функции. Иногда вычисление значения происходит таким образом, что лучше инкапсулировать его в функции (см. рекомендацию 11).
Пример 3. Инициализация массивов. Для больших составных типов, таких как массивы, корректная инициализация не всегда означает реальное обращение к данным. Пусть, например, вы используете API, который заставляет вас использовать фиксированные массивы char размера
Более безопасная инициализация заполняет все элементы массива нулевыми значениями:
Рекомендованы оба варианта, но в общем случае вы должны предпочитать безопасность излишней эффективности.
Входные буферы и данные, описанные как
[Dewhurst03] §48 • [Stroustrup00] §4.9.5, §6.3
20. Избегайте длинных функций и глубокой вложенности
Краткость — сестра таланта. Чересчур длинные функции и чрезмерно вложенные блоки кода зачастую препятствуют реализации принципа "одна функция — одна задача" (см. рекомендацию 5), и обычно эта проблема решается лучшим разделением задачи на отдельные части.