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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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 )

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Пусть компилятор выполнит работу.

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

Ответ 18

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

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