Warnings: чому це майбутні баги

1. Чому попередження перетворюються на баги

Коли ви вперше бачите попередження, часто виникає дивне відчуття: «Програма ж зібралася. Отже, усе гаразд?». Це як отримати повідомлення від лікаря: «Жити будете, але ось цю плямку я б перевірив». Формально все начебто добре, але розумна людина не вдаватиме, ніби плямка — це просто дизайнерське рішення організму.

Попередження — це діагностичне повідомлення компілятора про те, що код формально допустимий, але виглядає підозріло: можлива логічна помилка, неявна втрата даних, неініціалізоване значення, дивне порівняння типів, забутий return, умова, яка «майже завжди істинна або хибна», тощо. Компілятор не вміє читати думки, зате вміє розпізнавати тисячі шаблонів, які зазвичай завершуються багом.

Є один важливий нюанс: попередження — це не частина «мови C++», а особливість конкретного компілятора та його налаштувань. Один компілятор може попередити, інший — промовчати; IDE може підсвітити проблему, а веб-IDE — показати її лише за певних налаштувань. Але якщо попередження зʼявилося, це майже завжди корисний сигнал, тож ставитися до нього варто серйозно.

Як компілятор «вгадує» біду

Якщо спростити, компілятор попереджає вас не тому, що він шкідливий, а тому, що вже бачив цей фільм — і не раз. «Змінну оголошено, але не використано» — зазвичай це забутий шматок логіки; «порівняння signed і unsigned» — зазвичай це цикл, який раптово перестає працювати на межі; «неявне перетворення з втратою даних» — зазвичай це тихе спотворення результату, яке ви помітите лише за три тижні, коли в користувача зʼявиться «дивна статистика».

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

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

До речі, навіть у текстах та інструментах довкола C++ слово «warnings» трапляється в неочікуваних контекстах: наприклад, під час підготовки документів можуть виправляти warnings верстки. Так, у LaTeX теж є warnings про «переповнені рядки». Тобто сама культура розробки давно живе за принципом: warning — це не прикраса, а сигнал.

Як читати попередження без паніки

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

На практиці майже будь-яке попередження можна розібрати за одним сценарієм. Спочатку подивіться на координати: файл, рядок, іноді колонку. Потім прочитайте текст попередження і, якщо компілятор це показує, «імʼя попередження» або його категорію. Далі поставте собі запитання: «Що я хотів цим кодом виразити?». І останній крок — зрозуміти, як зробити цей намір явним, щоб ані компілятор, ані людина в майбутньому нічого не вгадували.

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

2. Приклад: TodoLite і типові попередження

Щоб попередження не залишалися абстрактною філософією, а ставали практикою, продовжимо наш невеликий консольний застосунок TodoLite. Він зберігає список завдань у std::vector, уміє додавати завдання та друкувати список. Ми не робимо тут повноцінний продукт і не намагаємося перемогти Jira. Нам важливо, щоб приклад був живим, а попередження виникали в цілком реальних місцях.

Уявімо, що в нас є структура завдання та простий друк:

// task.hpp
#pragma once
#include <string>

struct Task {
    int id = 0;
    std::string title;
    bool done = false;
};

// print.cpp
#include <iostream>
#include <vector>
#include "task.hpp"

void printTasks(const std::vector<Task>& tasks) {
    for (const Task& t : tasks) {
        std::cout << t.id << ") " << t.title << (t.done ? " [x]" : " [ ]") << '\n';
    }
}

Поки що все виглядає невинно. Але далі ми почнемо додавати функціональність, а разом із нею зʼявляться й типові попередження.

unused variable: змінна є, а сенсу немає

Зазвичай таке попередження зʼявляється, коли ви спочатку щось писали, потім передумали, а «артефакт» залишився. Це не завжди помилка, але дуже часто — слід незавершеної логіки. А незавершена логіка — це як недоварені макарони: формально їжа, але радості мало.

Припустімо, ви вирішили завести лічильник виконаних завдань, але поки що його не використовуєте:

#include <iostream>
#include <vector>
#include "task.hpp"

int countDone(const std::vector<Task>& tasks) {
    int doneCount = 0;
    for (const Task& t : tasks) {
        if (t.done) ++doneCount;
    }

    int total = static_cast<int>(tasks.size()); // warning: unused variable?
    return doneCount;
}

Якщо total ніде не використовується, компілятор цілком слушно запитує: «А навіщо ви це зробили?». У 80 % випадків відповідь така: «Я хотів, але забув». У 20 % — «Роблю це на майбутнє», але тоді краще або справді використати змінну, або явно позначити її як невикористовувану, щоб не накопичувати шум.

Найкраще лікування — або видалити змінну, або доробити логіку. Наприклад, якщо ви хотіли друкувати статистику:

#include <iostream>
#include <vector>
#include "task.hpp"

void printStats(const std::vector<Task>& tasks) {
    int doneCount = 0;
    for (const Task& t : tasks) if (t.done) ++doneCount;

    const int total = static_cast<int>(tasks.size());
    std::cout << "Done: " << doneCount << "/" << total << '\n'; // Done: 2/5
}

І попередження зникає, бо тепер намір очевидний: змінна потрібна для виведення.

Signed/unsigned у циклах

Це одне з най«улюбленіших» попереджень у C++. Воно особливо часто трапляється, коли індекс має тип int, а розмір контейнера — тип size_t, тобто беззнаковий тип. На невеликих прикладах усе працює нормально, і саме тому пастка така підступна: ви звикаєте до думки, що «і так зійде».

Подивімося на типовий код друку через індекси:

#include <iostream>
#include <vector>
#include "task.hpp"

void printTasksIndex(const std::vector<Task>& tasks) {
    for (int i = 0; i < tasks.size(); ++i) {   // warning: signed/unsigned
        std::cout << tasks[i].title << '\n';
    }
}

Чому це небезпечно? Бо порівняння int і size_t спричиняє неявні перетворення. У граничних випадках це може дати неочікуваний ефект, особливо якщо десь зʼявиться відʼємне значення, наприклад коли ви робите i-- або обчислюєте індекс як різницю.

На поточному рівні лікування зазвичай одне з двох: або ви використовуєте std::size_t як індекс, або взагалі відмовляєтеся від індексів на користь range‑for, якщо індекс вам не потрібен.

Варіант зі std::size_t:

#include <cstddef>
#include <iostream>
#include <vector>
#include "task.hpp"

void printTasksIndex(const std::vector<Task>& tasks) {
    for (std::size_t i = 0; i < tasks.size(); ++i) {
        std::cout << tasks[i].title << '\n';
    }
}

Варіант із range‑for, який часто читається ще краще:

#include <iostream>
#include <vector>
#include "task.hpp"

void printTasksRange(const std::vector<Task>& tasks) {
    for (const Task& t : tasks) {
        std::cout << t.title << '\n';
    }
}

Важлива думка: попередження тут не про «стиль», а про ризик. Компілятор бачить потенційну діру в логіці на межах і чесно підіймає прапорець.

Неявні перетворення і втрата даних

Втрата даних під час перетворень — класика, бо програма продовжує працювати. Вона не падає, не кричить, не димить. Вона просто починає казати вам неправду. А це в певному сенсі гірше за падіння: падіння хоча б помітне.

У TodoLite ми можемо захотіти зберігати «оцінку складності» завдання як число з дробовою частиною, але десь випадково записати це значення в int:

#include <iostream>

int main() {
    double effort = 2.7;
    int effortRounded = effort; // warning: conversion loses data?
    std::cout << effortRounded << '\n'; // 2
}

Якщо ви справді хочете відкинути дробову частину, зробіть це явно. Хоча б так:

#include <iostream>

int main() {
    double effort = 2.7;
    int effortFloored = static_cast<int>(effort);
    std::cout << effortFloored << '\n'; // 2
}

Чому це краще? Бо static_cast — це ваш підпис: «Так, я знаю, що дробова частина втратиться, і мене це влаштовує». Якщо ж ви не хотіли її втрачати, тоді попередження буквально заощадило вам час, указавши на місце, де логіка пішла не туди.

Підозрілі умови

Це той випадок, коли компілятор поводиться як уважний викладач: «Ви точно цього хотіли?». У C++ вираз присвоювання повертає значення, тому він може стояти в if. Іноді це використовують навмисно, але новачкам така можливість частіше приносить сюрпризи.

Приклад:

#include <iostream>

int main() {
    int menu = 0;

    if (menu = 1) {                // warning: assignment in condition
        std::cout << "Add task\n";  // Add task
    }
}

Код компілюється. І навіть працює «стабільно». Тільки завжди заходить у гілку, бо menu = 1 присвоює 1, а 1 — це true. У реальній програмі це може виглядати так: «Меню завжди вибирає один пункт, а я не розумію чому».

Правильний варіант — порівняння:

#include <iostream>

int main() {
    int menu = 0;

    if (menu == 1) {
        std::cout << "Add task\n";
    }
}

Так, це банально. Але саме банальні баги трапляються найчастіше: бо мозок утомився, бо ви поспішали, бо «і так зрозуміло». Попередження в таких місцях — як звуковий сигнал заднього ходу у вантажівки: неприємний, зате стіни залишаються цілішими.

[[nodiscard]] і ігнорування результату

Є окремий клас ситуацій: функція повертає щось важливе, наприклад ознаку успіху, а ви викликаєте її як «просто дію» й ігноруєте результат. Компілятор не зобовʼязаний через це сваритися, але C++ дозволяє явно позначити результат як «не ігноруй».

Нехай у нас у TodoLite є функція, яка намагається позначити завдання виконаним і повідомляє, чи вдалося це зробити:

// storage.hpp
#pragma once
#include <vector>
#include "task.hpp"

[[nodiscard]] bool markDone(std::vector<Task>& tasks, int id);

А в main.cpp ми написали так:

#include <vector>
#include "storage.hpp"

int main() {
    std::vector<Task> tasks;
    markDone(tasks, 10); // warning: ignoring nodiscard result?
}

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

Мінімальне лікування — хоча б використати результат:

#include <iostream>
#include <vector>
#include "storage.hpp"

int main() {
    std::vector<Task> tasks;

    if (!markDone(tasks, 10)) {
        std::cout << "No such task\n"; // No such task
    }
}

3. Часті попередження: шпаргалка

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

unused variable / unused parameter

signed/unsigned comparison

std::size_t

implicit conversion loses precision

static_cast

assignment in condition

=

==

ignoring [[nodiscard]]

4. Типові помилки під час роботи з попередженнями

Помилка № 1: «Попередження — це не помилки, тож можна ігнорувати».
Таке мислення працює рівно до першого випадку, коли програма «ніби працює», але час від часу видає неправильний результат. Попередження — це майже завжди повідомлення про те, що код допускає двозначне трактування. Якщо намір не виражено явно, баг стає лише питанням часу.

Помилка № 2: «Заглушу попередження чим завгодно, аби збирання було тихим».
Іноді студент бачить попередження й робить перше-ліпше приведення типу або додає якийсь «магічний» код, аби все замовкло. У підсумку попередження зникає, а баг залишається — тільки тепер він краще замаскований. Правильніше спочатку зрозуміти, що саме компілятор вважає ризикованим, і лише потім вибирати рішення.

Помилка № 3: «Додам static_cast як універсальний пластир».
static_cast — добрий інструмент, але він не має бути способом «змусити компілятор замовкнути». Кожне явне приведення повинне відповідати на запитання: чому це безпечно і що саме я хочу отримати. Якщо відповіді немає, краще змінити тип змінної або алгоритм, а не «заклинати» вираз.

Помилка № 4: «Буду виправляти попередження потім, коли все запрацює».
Це дуже схоже на обіцянку «потім приберу на столі, коли закінчу працювати». От тільки «потім» зазвичай настає того самого дня, що й дедлайн. Чим раніше ви привчаєтеся підтримувати код без попереджень, тим легше помічати нові проблеми: попередження, яке щойно зʼявилося, стає подією, а не фоновим шумом.

Помилка № 5: «У мене попередження про signed/unsigned, але на моїх трьох завданнях усе нормально».
Порівняння int і size_t рідко ламається на малих даних, зате дуже любить ламатися на порожньому контейнері, на великих розмірах або в логіці «йдемо назад». Попередження тут сигналізує не про поточний результат, а про те, що зі зміною умов код може поїхати.