Предупреждения компилятора C / C++: вы очищаете весь свой код, чтобы удалить его, или оставьте его?

Я бы убрал любое предупреждение. Даже те, о которых вы знаете, безвредны (если такие существуют), произведут о вас плохое впечатление у тех, кто будет компилировать код.

Это один из «вонючих» признаков, на которые я бы обратил внимание, если бы мне пришлось работать над чужим кодом.

Если бы не настоящие ошибки или потенциальные проблемы в будущем, это было бы признаком небрежности.

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

В моей работе включен параметр компилятора для обработки предупреждений как ошибок. Итак, никаких предупреждений, иначе он не будет компилироваться :)

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

Хотя некоторые предупреждения могут быть безобидными, большинство указывает на настоящую проблему с кодом.

Если вы не удалите все свои предупреждения, список предупреждений будет продолжать расти, а реальные проблемные случаи будут потеряны в море предупреждающего шума.

Кодовая база, над которой я работаю, содержит более 4000 предупреждений. Некоторые из них - настоящие проблемы. Нам никогда не дается времени, чтобы заняться их исправлением или рефакторингом других неисправных вещей ... Отчасти это связано с тем, что код настолько старый, что предшествует стандартизированному C++. Мы можем компилировать только на VC++ 6.

Одна из характеристик действительно хорошего программиста - то, что плохой код вызывает у него тошноту.

Я стремлюсь, чтобы весь мой код был не только чистым в компиляторе, но и был чистым внутри моей IDE, установленной на довольно разборчивом уровне. Иногда мне нужно подавить экземпляр предупреждения, если я знаю лучше, чем инструмент, но, по крайней мере, это также служит документацией.

Хуже всего то, что когда вы пишете новый код, трудно понять, не ввели ли вы случайно больше предупреждений, поскольку их так много, что вы все равно их игнорируете.

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

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

Предупреждения следует рассматривать как ошибки. Если вы не можете кодировать достаточно хорошо, чтобы избавиться от предупреждений, вам, вероятно, не следует писать код. В моей группе мы приняли решение преобразовывать все предупреждения в ошибки. Это полностью завершает это обсуждение и действительно, ИМХО, улучшает качество кода.

Всегда удаляйте все предупреждения или явно подавляйте их, если необходимо. Параметры по умолчанию для предупреждений должны быть максимально возможными при компиляции (например, уровень 4 в VS).

Я согласен, что лучше удалить все предупреждения. Если вы получаете тысячи предупреждений, вам следует расставить приоритеты для исправлений.

Начните с настройки вашего компилятора на самый низкий уровень предупреждений. Эти предупреждения должны быть самыми важными. Когда они будут устранены, увеличьте уровень предупреждения и повторяйте его, пока не достигнете наивысшего уровня предупреждения. Затем установите параметры компиляции таким образом, чтобы предупреждения обрабатывались как ошибки.

Если вы обнаружите предупреждение, которое, как вы подозреваете, можно игнорировать, проведите небольшое исследование, чтобы проверить свою теорию. Только после этого отключите его и только самым минимальным способом. Большинство компиляторов имеют директивы #pragma, которые могут отключать / включать предупреждения только для части файла. Вот пример Visual C++:

typedef struct _X * X; // from external header, not 64-bit portable

#pragma warning( push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )

Обратите внимание, что это отключает предупреждение только для одной строки кода. Использование этого метода также позволяет вам выполнять простой текстовый поиск вашего кода в будущем для внесения изменений.

В качестве альтернативы вы обычно можете отключить конкретное предупреждение для одного файла или для всех файлов. ИМХО это опасно и должно использоваться только в крайнем случае.

Убери их если возможно. На базе кода с несколькими платформами / компиляторами (я работал над кодовой базой, которая скомпилирована на 7 разных ОС с 6 разными компиляторами), это не всегда возможно. Я видел случаи, когда компилятор был просто неправильный (HP-UX aCC на Itanium, я смотрю на вас), но это, по общему признанию, редкость. Как отмечают другие, вы можете отключить предупреждение в такой ситуации.

Часто предупреждение в этой версии компилятора может стать ошибкой в ​​следующей версии (любой, кто обновляется с gcc 3.x до 4.x, должен быть знаком с этим), так что очистите его сейчас.

Некоторые компиляторы будут выдавать действительно полезные предупреждения, которые могут стать проблемами при определенных обстоятельствах - Visual C++ 2005 и 2008 могут предупреждать вас о 64-битных проблемах, что в настоящее время является ОГРОМНЫМ преимуществом. Если у вас есть какие-либо планы по переходу на 64-разрядную версию, простая очистка таких предупреждений значительно сократит время переноса.

В некоторых случаях я оставляю предупреждения в коде или когда их невозможно очистить (хотя я удаляю те, которые могу). Например:

• Если у вас есть что-то, над чем вы работаете, и вы знаете, что это требует дополнительной работы / внимания, оставьте предупреждение, чтобы указать, что это может быть уместно
• Если вы компилируете C++ с / clr, есть несколько предупреждений о вещах, которые вызывают генерацию машинного кода; может быть обременительным подавление всех этих предупреждений, когда кодовая база не может быть функционально изменена
• Удаление предупреждений, когда вы не понимаете, что делает исправление. Я делал это пару раз с предупреждением PC-Lint и в конечном итоге вносил ошибки. Если вы не знаете, каков точный эффект от изменения (например: приведение типов в стиле C для устранения предупреждений), НЕ делайте этого. Я советую выяснить предупреждение или оставить код в покое.

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

Я работал с рядом встроенных систем, в которых предупреждения приводят к нестабильности, сбоям или повреждению памяти. Если вы не знаете, что предупреждение безобидно, с ним нужно разобраться.

Оставлять предупреждения в коде, потому что у вас нет времени на их исправление, - все равно что не чистить зубы, потому что вам не хватает времени утром. Это основной вопрос гигиены кода.

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

Если есть предупреждения, то вам нужно проверить каждое, чтобы убедиться в отсутствии проблем. Делать это снова и снова - пустая трата времени. Если этого не сделать, это приведет к появлению ошибок в вашем коде.

Есть способы удалить предупреждение (например, #pragma argsused).

Пусть компилятор сделает всю работу.

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

Когда у меня есть время, я прохожу и убираю все, что могу.

Я пытаюсь скомпилировать код с довольно высоким уровнем предупреждений и очистить их все, за исключением предупреждений о «подписанном / неподписанном сравнении», которые, я уверен, я должен исправить, но никогда не беспокоюсь.

Краткая версия: в g ++ я использую «-Wextra -Wno-sign-compare» и избавляюсь от всех сообщений.