Чи "завжди ініціалізація змінних" не призводить до того, що важливі помилки приховуються?

Основні вказівки C ++ мають правило ES.20: Завжди ініціалізувати об'єкт .

Уникайте використаних раніше встановлених помилок та пов'язаних з ними невизначених поведінок. Уникайте проблем із розумінням складної ініціалізації. Спростіть рефакторинг.

Але це правило не допомагає знаходити помилок, воно лише їх приховує.
Припустимо, що програма має шлях виконання, де вона використовує неініціалізовану змінну. Це клоп. Не визначена поведінка в стороні, це також означає, що щось пішло не так, і програма, ймовірно, не відповідає його вимогам до продукту. Коли він буде розгорнутий на виробництво, може статися грошова втрата або навіть гірше.

Як ми перевіряємо помилки? Ми пишемо тести. Але тести не охоплюють 100% шляхів виконання, а тести ніколи не охоплюють 100% програмних даних. Більше того, навіть тест охоплює несправний шлях виконання - він все ще може пройти. Адже це не визначена поведінка, неініціалізована змінна може мати дещо дійсне значення.

Але крім наших тестів, у нас є компілятори, які можуть написати щось на зразок 0xCDCDCDCD до неініціалізованих змінних. Це трохи покращує швидкість виявлення тестів.
Ще краще - існують такі інструменти, як Address Sanitizer, які будуть вловлювати всі прочитані неініціалізовані байти пам'яті.

І нарешті, є статичні аналізатори, які можуть подивитися на програму і сказати, що на цьому шляху виконання є попереднє встановлення.

Отже, у нас є багато потужних інструментів, але якщо ми ініціалізуємо змінну - дезінфікуючі засоби нічого не знаходять .

int bytes_read = 0;
my_read(buffer, &bytes_read); // err_t my_read(buffer_t, int*);
// bytes_read is not changed on read error.
// It's a bug of "my_read", but detection is suppressed by initialization.
buffer.shrink(bytes_read); // Uninitialized bytes_read could be detected here.

// Another bug: use empty buffer after read error.
use(buffer);

Існує ще одне правило - якщо при виконанні програми зустрічається помилка, програма повинна загинути якнайшвидше. Не потрібно підтримувати його живим, просто розбийте, напишіть аварійний відвал, дайте інженерам для розслідування.
Ініціалізація змінних доводиться навпаки - програма зберігається в живих, коли в іншому випадку вона вже отримає помилку сегментації.

Ваші міркування помиляються в кількох записах:

1. Порушення сегментації далеко не певні. Використання неініціалізованої змінної призводить до невизначеної поведінки . Недоліки сегментації - це один із способів прояву такої поведінки, але здається нормальним.
2. Компілятори ніколи не заповнюють неініціалізовану пам'ять визначеним малюнком (наприклад, 0xCD). Це те, що деякі налагоджувачі роблять, щоб допомогти вам знайти місця, де неініціалізовані змінні звикають. Якщо ви запускаєте таку програму поза налагоджувачем, то змінна міститиме абсолютно випадковий сміття. Не менш ймовірно, що лічильник на зразок значення bytes_readмає таке значення, 10як і значення 0xcdcdcdcd.
3. Навіть якщо ви працюєте в відладчику, який встановлює неініціалізовану пам'ять на фіксовану схему, вони роблять це лише при запуску. Це означає, що цей механізм надійно працює лише для статичних (і, можливо, виділених в купу) змінних. Для автоматичних змінних, які виділяються на стеку або живуть лише в регістрі, велика ймовірність, що змінна зберігається в місці, яке раніше використовувалося, тому шаблон пам'яті розповідачів уже був перезаписаний.

Ідея вказівок завжди ініціалізувати змінні полягає у включенні цих двох ситуацій

1. Змінна містить корисне значення прямо з самого початку свого існування. Якщо ви поєднаєте це із вказівкою щодо оголошення змінної лише після того, як вам це потрібно, ви можете уникнути майбутніх програмістів технічного обслуговування, які потрапляють у пастку, починаючи використовувати змінну між її декларацією та першим призначенням, де змінна існувала б, але не була ініціалізована.

2. Змінна містить визначене значення, яке ви можете протестувати пізніше, щоб визначити, чи функція на зразок my_readоновила значення. Без ініціалізації ви не можете визначити, чи bytes_readдійсно має дійсне значення, оскільки ви не можете знати, з якого значення воно почалося.

Ви писали: "це правило не допомагає знаходити помилок, воно лише їх приховує" - ну, мета правила - не допомогти у пошуку помилок, а уникнути їх. А коли уникнути помилок, нічого прихованого немає.

Давайте вирішуватимете питання на прикладі: припустимо, my_readфункція має письмовий договір про ініціалізацію bytes_readза будь-яких обставин, але це не відбувається у випадку помилки, тому вона несправна, принаймні, для цього випадку. Ваш намір полягає в тому, щоб використовувати середовище часу виконання, щоб показати цю помилку, не ініціалізуючи bytes_readпараметр спочатку. Поки ви точно знаєте, що на місці є дезінфікуюча адреса, це дійсно можливий спосіб виявити таку помилку. Щоб виправити помилку, потрібно змінитиmy_read внутрішньо функцію.

Але існує інша точка зору, яка, принаймні, однаково справедлива: несправна поведінка виникає лише з комбінації не ініціалізації bytes_readзаздалегідь, а виклику my_readпісля цього (з очікуванням bytes_readініціалізується після цього). Це ситуація, яка часто трапляється в компонентах реального світу, коли письмова специфікація для функції на зразок my_readне є на 100% зрозумілою, або навіть неправильною щодо поведінки у випадку помилки. Однак, поки bytes_readперед викликом ініціалізується до нуля, програма поводиться так само, як якщо б ініціалізація була зроблена всередині my_read, тому вона веде себе правильно, в цій комбінації помилок у програмі немає.

Тож моя рекомендація, яка випливає з цього, полягає в тому, щоб використовувати підхід, який не ініціалізується, лише якщо

• ви хочете перевірити, чи функція або блок коду ініціалізує певний параметр
• ви на 100% впевнені, що функція в пакеті має контракт, коли напевно неправильно не призначати значення цьому параметру
• ви на 100% впевнені, що навколишнє середовище може це зловити

Це умови, які типово можна домовитись у тестовому коді для конкретного інструментального середовища.

Однак у виробничому коді краще завжди ініціалізувати таку змінну заздалегідь, це тим більше захисний підхід, який запобігає помилкам у випадку, якщо договір є неповним чи неправильним, або у випадку, якщо адресатизатор або подібні заходи безпеки не активовані. І, як ви правильно писали, застосовується правило "раннього аварійного завершення", якщо виконання програми зустрічається з помилкою. Але коли ініціалізація змінної заздалегідь означає, що немає нічого поганого, тоді не потрібно зупиняти подальше виконання.

Завжди ініціалізуйте свої змінні

Різниця між ситуаціями, які ви розглядаєте, полягає в тому, що випадок без ініціалізації призводить до невизначеної поведінки , тоді як випадок, коли ви витратили час на ініціалізацію, створює чітко визначену та детерміновану помилку. Я не можу підкреслити, наскільки надзвичайно різні ці два випадки достатньо.

Розглянемо гіпотетичний приклад, який, можливо, стався з гіпотетичним працівником за програмою гіпотетичного моделювання. Ця гіпотетична команда гіпотетично намагалася зробити детерміновану імітацію, щоб продемонструвати, що продукт, який вони продавали гіпотетично, задовольняв потреби.

Гаразд, я зупинюсь на словах ін’єкції. Я думаю, ти зрозумієш справу ;-)

У цьому моделюванні було сотні неініціалізованих змінних. Один розробник запустив valgrind на моделювання і помітив, що існує кілька помилок "гілки на неініціалізовані значення". "Гм, це виглядає так, що може спричинити недетермінізм, що ускладнить повторення тестових прогонів, коли це нам найбільше потрібно". Розробник перейшов до менеджменту, але менеджмент був дуже щільним, і не міг заощадити ресурси, щоб знайти цю проблему. "Ми закінчуємо ініціалізацію всіх наших змінних, перш ніж їх використовувати. У нас є хороші методи кодування."

За кілька місяців до остаточної здачі, коли моделювання перебуває в режимі повного збиття, і вся команда працює на завершення всіх речей, обіцяних управлінням бюджету, який, як і кожен проект, який коли-небудь фінансувався, був надто малим. Хтось зауважив, що вони не можуть перевірити істотну особливість, оскільки, з якоїсь причини, детермінований сим не поводився детерміновано до налагодження.

Весь колектив, можливо, був зупинений і витратив більшу частину 2 місяця, розчісуючи всю кодову базу імітації, виправляючи неініціалізовані помилки значення замість реалізації та тестування функцій. Потрібно сказати, що працівник пропустив "Я сказав вам так" і пішов прямо допомагати іншим розробникам зрозуміти, що таке неініціалізовані значення. Як не дивно, стандарти кодування були змінені незабаром після цього інциденту, спонукаючи розробників завжди ініціалізувати свої змінні.

І це попереджувальний постріл. Це куля, яка пасеться через ніс. Справжнє питання є набагато куди більш підступним, ніж ви навіть уявляєте.

Використання неініціалізованого значення - це "невизначена поведінка" (за винятком кількох кутових випадків, таких як char). Невизначена поведінка (або UB коротко) настільки шалено і абсолютно погано для вас, що ви ніколи не повинні вірити, що це краще, ніж альтернатива. Іноді ви можете визначити, що ваш конкретний компілятор визначає UB, а потім його безпечний для використання, але в іншому випадку невизначена поведінка - це "будь-яка поведінка, якою компілятор відчуває себе подібною". Це може зробити щось, що ви б назвали "розумним", як, наприклад, не визначене значення. Він може видавати недійсні коди, що може призвести до пошкодження вашої програми. Це може викликати попередження під час компіляції, або компілятор навіть може вважати це помилкою.

Або може взагалі нічого не робити

Моя канарка у вугільній шахті для UB - це випадок із двигуна SQL, про який я читав. Пробачте, що не пов’язував це, я не зміг знайти статтю знову. Виникла проблема з перевищенням буфера в SQL-двигуні, коли ви передали більший розмір буфера функції, але тільки для певної версії Debian. Клоп старанно ввійшов у систему та дослідив. Найсмішніша частина була: перевірено перевиконання буфера . Був код для обробки перекриття буфера на місці. Це виглядало приблизно так:

// move the pointers properly to copy data into a ring buffer.
char* putIntoRingBuffer(char* begin, char* end, char* get, char*put, char* newData, unsigned int dataLength)
{
    // If dataLength is very large, we might overflow the pointer
    // arithmetic, and end up with some very small pointer number,
    // causing us to fail to realize we were trying to write past the
    // end.  Check this before we continue
    if (put + dataLength < put)
    {
        RaiseError("Buffer overflow risk detected");
        return 0;
    }
    ...
    // typical ring-buffer pointer manipulation followed...
}

Я додав більше коментарів у моїй передачі, але ідея така ж. Якщо put + dataLengthобернути навколо, він буде меншим, ніж putпокажчик (вони мали перевірити час складання, щоб переконатися, що неподписаний int був розміром вказівника, для допитливих). Якщо це трапиться, ми знаємо, що стандартні алгоритми буферного дзвінка можуть заплутатися в результаті цього переповнення, тому повертаємо 0. Або ми?

Як виявляється, переповнення покажчиків не визначено в C ++. Оскільки більшість компіляторів розглядають покажчики як цілі числа, ми закінчуємо типовою цілочисельною поведінкою переповнення, яка трапляється як така поведінка, яку ми хочемо. Тим НЕ менше, це є невизначеним поведінкою, тобто компілятор має право робити що - небудь вона хоче.

У разі цієї помилки, Debian була вибрати , щоб використовувати нову версію GCC , що жоден з інших основних смаків Linux не оновив в своїх виробничих випусках. Ця нова версія gcc мала більш агресивний оптимізатор мертвого коду. Компілятор побачив невизначену поведінку і вирішив, що результатом ifзаяви буде "все, що робить оптимізацію коду найкращою", що було абсолютно законним перекладом UB. Відповідно, було зроблено припущення, що оскільки ptr+dataLengthніколи не може бути нижче ptrбез переповнення вказівника UB, ifоператор ніколи не запустить, і оптимізував перевірку перевиконання буфера.

Використання "розумного" UB фактично призвело до того, що у великого продукту SQL було застосовано функцію перевиконання буфера, щоб уникнути написаного коду!

Ніколи не покладайтеся на невизначену поведінку. Колись.

Я здебільшого працюю на мові функціонального програмування, де вам заборонено перепризначати змінні. Колись. Це повністю виключає цей клас помилок. Спочатку це здавалося величезним обмеженням, але це змушує вас структурувати свій код таким чином, що відповідає порядку, коли ви дізнаєтесь нові дані, що, як правило, спрощує ваш код і полегшує його обслуговування.

Ці звички також можна перенести на загальнообов'язкові мови. Практично завжди можна перефактурувати свій код, щоб уникнути ініціалізації змінної з фіктивним значенням. Ось, що ці настанови говорять вам робити. Вони хочуть, щоб ви помістили щось значиме, а не те, що просто зробить автоматизовані інструменти щасливими.

Ваш приклад з API в стилі C трохи більш складний. У тих випадках, коли я використовую функцію, я ініціалізуюсь до нуля, щоб утримувач не скаржився, але один раз в my_readодиничних тестах я ініціалізую щось інше, щоб переконатися, що стан помилки працює належним чином. Вам не потрібно перевіряти кожен можливий стан помилок при кожному використанні.

Ні, помилки не приховують. Натомість це робить поведінку детермінованою таким чином, що якщо користувач стикається з помилкою, розробник може її відтворити.

TL; DR: Є два способи зробити цю програму правильною, ініціалізувати свої змінні та молитися. Лише один дає результати послідовно.

Перш ніж я зможу відповісти на ваше запитання, мені потрібно спочатку пояснити, що означає Невизначена поведінка . Насправді я дозволю автору-компілятору виконати основну частину роботи:

• Що повинен знати кожен програміст на C щодо не визначеної поведінки №1 / 3
• Що повинен знати кожен програміст на C щодо не визначеної поведінки №2 / 3
• Що повинен знати кожен програміст на C щодо не визначеної поведінки №3 / 3

Якщо ви не бажаєте читати ці статті, TL; DR:

Undefined Behavior - це соціальний договір між розробником та компілятором; компілятор із сліпою вірою припускає, що його користувач ніколи і ніколи не покладатиметься на Невизначене поведінку.

Архетип "Демонів, що літають з вашого носа", на жаль, не зміг передати наслідки цього факту. Хоча мав на меті довести, що все може статися, це було настільки неймовірно, що воно здебільшого знизало плечима.

Однак правда полягає в тому, що Undefined Behavior впливає на саму компіляцію , задовго до того, як ви навіть спробуєте скористатися програмою (інструментально чи ні, у відладчику чи ні) і зможете повністю змінити її поведінку.

Я вважаю приклад у частині 2 вище яскравим:

void contains_null_check(int *P) {
  int dead = *P;
  if (P == 0)
    return;
  *P = 4;
}

перетворюється на:

void contains_null_check(int *P) {
  *P = 4;
}

тому що це очевидно, що цього Pне може бути, 0оскільки його відміняють перед тим, як перевірити.

Як це стосується вашого прикладу?

int bytes_read = 0;
my_read(buffer, &bytes_read); // err_t my_read(buffer_t, int*);
// bytes_read is not changed on read error.
// It's a bug of "my_read", but detection is suppressed by initialization.
buffer.shrink(bytes_read); // Uninitialized bytes_read could be detected here.

Що ж, ви зробили загальну помилку, вважаючи, що невизначена поведінка спричинить помилку під час виконання. Це не може.

Уявімо собі, що визначення my_read:

err_t my_read(buffer_t buffer, int* bytes_read) {
    err_t result = {};
    int blocks_read = 0;
    if (!(result = low_level_read(buffer, &blocks_read))) { return result; }
    *bytes_read = blocks_read * BLOCK_SIZE;
    return result;
}

і продовжуйте, як очікувалося, від хорошого компілятора з вбудованим:

int bytes_read; // UNINITIALIZED

// start inlining my_read

err_t result = {};
int blocks_read = 0;
if (!(result = low_level_read(buffer, &blocks_read))) {
    // nothing
} else {
    bytes_read = blocks_reads * BLOCK_SIZE;
}

// end of inlining my_read

buffer.shrink(bytes_read);

Тоді, як і очікувалося від хорошого компілятора, ми оптимізуємо непотрібні гілки:

1. Жодна змінна не повинна використовуватися неініціалізованою
2. bytes_readвикористовувались би неініціалізованими, якби resultне0
3. Розробник обіцяє, що resultніколи не буде 0!

Так resultніколи 0:

int bytes_read; // UNINITIALIZED
err_t result = {};
int blocks_read = 0;
result = low_level_read(buffer, &blocks_read);

bytes_read = blocks_reads * BLOCK_SIZE;
buffer.shrink(bytes_read);

О, resultніколи не використовується:

int bytes_read; // UNINITIALIZED
int blocks_read = 0;
low_level_read(buffer, &blocks_read);

bytes_read = blocks_reads * BLOCK_SIZE;
buffer.shrink(bytes_read);

О, ми можемо відкласти декларацію про bytes_read:

int blocks_read = 0;
low_level_read(buffer, &blocks_read);

int bytes_read = blocks_reads * BLOCK_SIZE;
buffer.shrink(bytes_read);

І ось ми - суворо підтверджуюча трансформація оригіналу, і жоден налагоджувач не захопить неініціалізовану змінну, оскільки її немає.

Я пішов по цій дорозі, розуміючи проблему, коли очікувана поведінка та збори не відповідають, насправді не цікаво.

Давайте докладніше розглянемо ваш приклад код:

int bytes_read = 0;
my_read(buffer, &bytes_read); // err_t my_read(buffer_t, int*);
// bytes_read is not changed on read error.
// It's a bug of "my_read", but detection is suppressed by initialization.
buffer.shrink(bytes_read); // Uninitialized bytes_read could be detected here.

// Another bug: use empty buffer after read error.
use(buffer);

Це хороший приклад. Якщо ми передбачаємо таку помилку, як ця, ми можемо вставити рядок assert(bytes_read > 0);і зафіксувати цю помилку під час виконання, що неможливо з неініціалізованою змінною.

Але припустимо, що ми цього не робимо, і ми виявляємо помилку всередині функції use(buffer). Ми завантажуємо програму в відладчик, перевіряємо зворотній слід і з'ясовуємо, що вона викликана з цього коду. Тому ми ставимо точку перерви у верхній частині цього фрагмента, запускаємо ще раз і відтворюємо помилку. Ми робимо один крок, намагаючись зловити його.

Якщо ми не ініціалізували bytes_read, він містить сміття. Це не обов'язково містить одне і те ж сміття кожного разу. Ми проходимо повз лінію my_read(buffer, &bytes_read);. Тепер, якщо це значення має інше значення, ніж раніше, ми можемо не вдасться відтворити нашу помилку! Це може спрацювати наступного разу, за тим же самим входом, при повній аварії. Якщо вона постійно дорівнює нулю, ми отримуємо послідовну поведінку.

Ми перевіряємо значення, можливо, навіть на відстані у тому ж циклі. Якщо він дорівнює нулю, ми можемо побачити, що щось не так; bytes_readне повинні бути нульовими на успіх. (Або, якщо це може бути, ми можемо захотіти ініціалізувати його до -1.) Тут ми, мабуть, можемо зловити помилку. Якщо bytes_readправдоподібне значення, однак, що це просто трапиться неправильно, ми би помітили це з першого погляду?

Особливо це стосується покажчиків: вказівник NULL завжди буде очевидним у налагоджувальній машині, його можна перевірити дуже легко, і він має бути за замовчуванням на сучасному обладнанні, якщо ми спробуємо його знеструмити. Сміттєвий покажчик може пізніше викликати невідтворювані помилки з пошкодженням пам’яті, і їх майже неможливо налагодити.

ОП не покладається на невизначену поведінку чи, принаймні, не зовсім. Дійсно, покладатися на невизначену поведінку погано. У той же час поведінка програми в несподіваному випадку також не визначена, але іншого виду не визначена. Якщо ви встановите змінну до нуля, але ви не мали наміру мати шлях виконання, який використовує цей початковий нуль, чи буде ваша програма поводитися нормально, коли у вас є помилка і чи є такий шлях? Ти зараз у бур'яні; ви не планували використовувати це значення, але все одно ви його використовуєте. Можливо, це буде нешкідливим, а може призведе до збою програми, а може призведе до того, що програма мовчки пошкодить дані. Ви не знаєте.

Що говорить ОП - це те, що є інструменти, які допоможуть вам знайти цю помилку, якщо ви дозволите їх. Якщо ви не ініціалізуєте значення, але потім все одно користуєтесь ним, є статичні та динамічні аналізатори, які скажуть вам, що у вас є помилка. Статичний аналізатор скаже вам, перш ніж ви навіть почнете тестувати програму. Якщо, з іншого боку, ви сліпо ініціалізуєте значення, аналізатори не можуть сказати, що ви не планували використовувати це початкове значення, і тому ваша помилка не виявиться. Якщо вам пощастило, це нешкідливо або просто виходить з ладу програма; якщо вам не пощастило, воно мовчки пошкоджує дані.

Єдине місце, з яким я не погоджуюсь з ОП, - це саме той кінець, де він каже: "коли б інакше була б помилка сегментації в іншому випадку". Дійсно, неініціалізована змінна не призведе до надійної помилки сегментації. Натомість я б сказав, що вам слід використовувати засоби статичного аналізу, які не дозволять вам дійти навіть до спроби виконати програму.

Відповідь на ваше запитання потрібно розділити на різні типи змінних, що з’являються всередині програми:

Локальні змінні

Зазвичай декларація повинна бути прямо на місці, де змінна вперше отримує своє значення. Не визначайте змінні, як у старому стилі C:

//Bad: predeclared variables
int foo = 0;
double bar = 0.0;
long* baz = NULL;

bar = getBar();
foo = (int)bar;
baz = malloc(foo);


//Correct: declaration and initialization at the same place
double bar = getBar();
int foo = (int)bar;
long* baz = malloc(foo);

Це знімає 99% потреби в ініціалізації, змінні мають остаточне значення прямо з вимкнення. Кілька винятків - ініціалізація залежить від певної умови:

Base* ptr;
if(foo()) {
    ptr = new Derived1();
} else {
    ptr = new Derived2();
}

Я вважаю, що добре написати такі випадки так:

Base* ptr = nullptr;
if(foo()) {
    ptr = new Derived1();
} else {
    ptr = new Derived2();
}
assert(ptr);

І. е. явно стверджують, що виконується деяка розумна ініціалізація вашої змінної.

Змінні учасника

Тут я погоджуюся з тим, що сказали інші відповіді: Вони завжди повинні бути ініціалізовані списками конструкторів / ініціалізаторів. Інакше вам важко забезпечити послідовність між своїми членами. І якщо у вас є набір членів, який, здається, не потребує ініціалізації у всіх випадках, перефактуруйте свій клас, додавши цих членів у похідний клас, де вони завжди потрібні.

Буфери

Тут я не згоден з іншими відповідями. Коли люди стають релігійними щодо ініціалізації змінних, вони часто закінчують ініціалізацію таких буферів:

char buffer[30];
memset(buffer, 0, sizeof(buffer));

char* buffer2 = calloc(30);

Я вважаю, що це майже завжди є корисним: Єдиний ефект цих ініціалізацій полягає в тому, що вони роблять інструменти на зразок valgrindбезсилими. Будь-який код, який читає більше з ініціалізованих буферів, ніж слід, дуже ймовірно помилка. Але при ініціалізації цей помилка не може бути виявлена valgrind. Тому не використовуйте їх, якщо ви по-справжньому не покладаєтесь на те, що пам'ять заповнена нулями (і в такому випадку залиште коментар, в якому сказано, для чого потрібні нулі).

Я також настійно рекомендую додати ціль до вашої системи збирання, яка запускає весь тестовий набір під valgrindабо подібним інструментом для викриття помилок використання перед ініціалізацією та витоків пам'яті. Це цінніше всіх попередніх ініціалізацій змінних. Цеvalgrind ціль слід виконувати регулярно, головне, перш ніж будь-який код стане загальним.

Глобальні змінні

У вас не може бути глобальних змінних, які не ініціалізовані (принаймні, на C / C ++ тощо), тому переконайтеся, що ця ініціалізація потрібна.

Пристойний компілятор C, C ++ або Objective-C з набором правильних параметрів компілятора підкаже вам під час компіляції, якщо використовується змінна до встановлення її значення. Оскільки в цих мовах використання значення неініціалізованої змінної є невизначеною поведінкою, "встановити значення перед використанням" не є підказом, не керівництвом, ні належною практикою, це 100% вимога; інакше ваша програма абсолютно зламана. В інших мовах, таких як Java та Swift, компілятор ніколи не дозволить вам використовувати змінну до її ініціалізації.

Існує логічна різниця між "ініціалізацією" та "встановленням значення". Якщо я хочу знайти коефіцієнт конверсії між доларами та євро, і написати "подвійний курс = 0,0;" то змінна має набір значень, але вона не ініціалізується. Збережений тут 0,0 не має нічого спільного з правильним результатом. У цій ситуації, якщо через помилку ви ніколи не зберігаєте правильний коефіцієнт конверсії, у компілятора немає шансу сказати вам. Якщо ви тільки що написали "подвійну ставку"; і ніколи не зберігав значущий коефіцієнт конверсії, скаже вам компілятор.

Отже: Не ініціалізуйте змінну лише тому, що компілятор каже вам, що вона використовується без ініціалізації. Це приховує помилку. Справжня проблема полягає в тому, що ви використовуєте змінну, яку ви не повинні використовувати, або що для одного кодового шляху ви не встановили значення. Виправте проблему, не приховуйте її.

Не ініціалізуйте змінну лише тому, що компілятор може сказати вам, що вона використовується без ініціалізації. Знову ж таки, ви приховуєте проблеми.

Заявіть змінні, близькі до використання. Це збільшує шанси на те, що ви можете ініціалізувати його зі значущим значенням у точці декларації.

Уникайте повторного використання змінних. Коли ви повторно використовуєте змінну, вона, швидше за все, ініціалізується на марне значення, коли ви використовуєте її з другою метою.

Було зауважено, що деякі компілятори мають помилкові негативи та перевірка на ініціалізацію еквівалентна проблемі зупинки. Обидва на практиці не мають значення. Якщо компілятор, як цитується, не може знайти використання неініціалізованої змінної через десять років після повідомлення про помилку, настав час шукати альтернативного компілятора. Java реалізує це двічі; один раз у компіляторі, один раз у верифікаторі, без проблем. Найпростіший спосіб вирішити проблему зупинки - це не вимагати, щоб змінна ініціалізувалася перед використанням, а щоб вона була ініціалізована перед використанням способом, який можна перевірити простим і швидким алгоритмом.