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

Question

В прошлом я работал с -Wall и другими ключами для gcc, чтобы исключить все предупреждения компилятора для проектов, в которых я принимал участие. Аналогично, на Perl я всегда программирую с использованием строгих правил и предупреждений об использовании (и часто - T), чтобы попытаться достичь наилучшего качества кода, которое я могу. Я понимаю, что несколько лет назад группа разработчиков Perl усердно работала над тем, чтобы заставить perl (интерпретатор Perl) корректно компилироваться в gcc со всеми включенными предупреждениями. Очевидно, они чувствовали, что это хорошая идея для качества кода. Я также понимаю, что в настоящее время программисты Perl добавляют еще больше предупреждений в свой код с помощью Perl :: Critic, который предупреждает их, когда они нарушают передовые методы, найденные в книге Perl Best Practices Дамиана Конвея (и из других источников, я полагаю).

У меня всегда было хорошее чувство в отношении кода, который я так очистил, но иногда я не мог избежать ощущения, что часть работы была немного потрачена впустую. Например, в моих вступительных классах C более десяти лет назад меня учили запускать функцию main () следующим образом:

void main(void) {

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

int main(int args, char* argv) {

Должно быть, я набрал пару сотен неиспользованных int args, char * argv в тот день. Действительно ли я улучшил свой код или просто укоротил пальцы?

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

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

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

Примечание : дубликат этого вопроса

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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