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

Question

Я работал над многими проектами, где другие дали мне код для обновления. Чаще всего я компилирую его и получаю более 1000 предупреждений компилятора. Когда я вижу предупреждения компилятора, они заставляют меня чувствовать себя грязно, поэтому моя первая задача - очистить код и удалить их все. Обычно я нахожу около десятка таких проблем, как неинициализированные переменные, такие.

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Если вы обнаружите предупреждение, которое, как вы подозреваете, безопасно игнорировать, проведите некоторое исследование, чтобы проверить свою теорию. Только тогда отключите это и только самым минимальным возможным способом. Большинство компиляторов имеют директивы #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 )

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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