Действительно ли это - хорошая идея устранить предупреждения компилятора?

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

существуют унаследованные системы, где некоторые (многие или все) компоненты без, специализированные обслуживающие и значительные части системы в основном неизвестны. Фиксация предупреждений компилятора в таком неизвестном коде может взять значительный объем кода (так как для каждого предупреждения кода вместе с его контекстом должен быть понят), и представляет возможный источник ошибок (некоторый код зависит от неопределенного поведения). И так как такие унаследованные системы редко имеют обширное тестовое покрытие, Вы не можете даже полагаться на тесты для уведомления Вас относительно регрессий.

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

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

Существует два совместимых прототипа для основного в C.

int main(void)

и

int main(int argc, char **argv)

void main(void) не технически корректно, хотя это может поддерживаться некоторыми компиляторами как расширение стандарта.

Так, в Вашем особом случае, можно использовать короткое объявление main и, если совместимый, он не инициирует предупреждение.

Да. Даже тривиальные стоит зафиксировать. Вот то, почему. Некоторых, как пример основного, которое Вы упоминаете, вероятно, не стоит фиксировать самостоятельно, но они находятся в агрегате. Большинство предупреждений компилятора сохранит Вас прямая боль в долгосрочной перспективе. Они - неизбежные ошибки (или даже происходящий теперь). Для нахождения их Вам нужен простой способ заметить их. Если Вы фиксируете все предупреждения, то каждое новое предупреждение является красным флагом и легкий заметить. Если Вы фиксируете все критические, но уезжаете, некоторым нравится одна только "основная" проблема, Вы пропустите новые критические.

, Который легче помнить? То, что какое-либо предупреждение должно быть зафиксировано или что у Вас было 23 несоответствующих предупреждения в этой кодовой базе вчера и поэтому если Вы видите 24, необходимо ли пойти, смотрят?

В кодовой базе я продолжаю работать, мы говорим компилятору генерировать ошибки на всех предупреждениях. Это вынуждает нас зафиксировать их и сохраняет код в намного лучшей форме. Если существует когда-нибудь предупреждение, которое действительно не стоит фиксировать, всегда существует #pragma, чтобы заставить его исчезнуть. Тем путем у Вас все еще есть яркая строка для отказа.

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

у Нас есть много кода, который был написан до Java 1.5 и дженериков. Это все еще работает. Eclipse также генерирует буквально тысячи предупреждений о непараметрических наборах. Практически все эти наборы ограничены в объеме; они никогда не собираются повреждаться. Но ожидайте, можно спросить; что относительно нескольких наборов, которые не ограничены в объеме? Разве Вы не рискующий набором, где-нибудь содержащим экземпляр чего-то, что никогда не должно идти туда?

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

Примечание протесты здесь, затем:

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

, Если любой из них прекращает быть верным - говорят, например, ошибка внезапно делает декларация, и мы должны войти и отредактировать - предупреждения внезапно становятся более стоящими для фиксации. (Кстати, они очень недороги для фиксации в этой точке, также; мы можем зафиксировать соответствующие блоки по пути, поскольку мы исправляем ошибку.)

Да, сделайте так..

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

Это был C-проект, и в одном источнике назвали sqrt (квадратный корень). Я получил соблюдающее предупреждение:

test.c:4: warning: implicit declaration of function 'sqrt'

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

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

Btw - фиксация предупреждений взяла меня как... 4 часа... Это - ничто по сравнению со временем, которое потребовалось для записи всего этого.

Eclipse, IntelliJ и другие современные качественные системы кода имеют огромные числа доступных предупреждений.

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

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

Только для добавления предупреждений вот что использование разработчика гнома в его коде:

http://blogs.gnome.org/otte/2008/12/22/warning-options/

Другая причина гарантировать, что Ваши компиляции кода без предупреждений - то, что, если кто-то еще* должен внести изменения в код в какой-то момент в будущем, хорошее место для запуска состоит в том, чтобы удостовериться, что они могут скомпилировать код в его текущей форме.

Однако, если они, это, и видеть много предупреждений, является этими предупреждениями, которые всегда существовали, или они установили компилятор неправильно на их ПК?

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

(* Кто-то еще может включать Ваше будущее сам).

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

Мое мнение. Да.

Как Вы сказал в конце. Это помогает совершить реальные более видные ошибки.

, Когда Вы выполняете Perl cgi сценарий, что выходные предупреждения на Сервере Apache, предупреждения зарегистрированы error.log. Почему отходы пространство. Зафиксируйте предупреждения.

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

Вашим примером является идеальная иллюстрация, почему предупреждения не должны быть проигнорированы. void main(void) недопустимый прототип (но int main(void) работы!)) и Ваш код может повредиться на некоторых компиляторах. Ваш компилятор был достаточно хорош указать на это.

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

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

Необходимо всегда пытаться не иметь никаких предупреждений, подошедших на компиляции. Тем путем новые предупреждения привлекают внимание. (Мой самый расстраивающий опыт когда-либо с этим был компилятором C++ AIX назад в 2002, который выложил сотни предупреждений для кода, который не был даже в большой степени шаблонным.)

Знают то, что означает каждое предупреждение. В Вашем случае необходимо было ввести стандарт int main(), а не неправильное void main(void) или более неуклюжее int main(int argc, char **argv). Устраните то, что Вы можете, и подавлять предупреждения, которые Вы считали приемлемыми.

Вы не можете хотеть фиксировать каждое предупреждение. Как saua говорит, существуют унаследованные системы, где фиксация предупреждений является совершенно опасными, и сложными системами как CGAL, где Вы не хотите унавоживать с кодом также. В преобразовании наших приложений для выполнения менее чем 64 битов я нашел случаи, где я мог устранить предупреждение только с броском, который потенциально вызовет другие проблемы. Мы подавили то предупреждение.