Линус о предупреждениях компилятора

Это 5

А ведь он в чем-то прав.

Если сформулировать по-человечески: Торвальдс ругается на то, что вместо того, чтобы исправить кривой код, человек прислал патч, который просто исправляет warnings копилятора, но сам код остается такой же кривой ("The old code was _also_ crap, but the new code just is worse"). И говорит, что в данном случае лучше оставить ворнинги, т.к. это жирное предупреждение в некомпетентности автора кода.

ИМХО на новость не тянет. Будем обсуждать каждое сообщение Торвальдса в LKML?

> Будем обсуждать каждое сообщение Торвальдса в LKML?

Я думаю достаточно составить список того, что Линус еще не обозвал словом crap.

да, на новость чуток не тянет (имхо). лучше б модеры сделали топик полезных цитат/высказываний и туда подобные вещи кидали.

talks есть для этого

>да, на новость чуток не тянет (имхо). лучше б модеры сделали топик полезных цитат/высказываний и туда подобные вещи кидали.

Лучше будут хоть какие-то новости, чем никаких.

тоже верно.

Выяснилось, что автора патча -- Andrew Morton, Торвальдс был в огорчении :)

>Выяснилось, что автора патча -- Andrew Morton, Торвальдс был в огорчении :)

:))

Да, на новость не тянет. Но всё-таки эту "новость" лучше оставить, чтобы некоторые кодеры задумывались. Полезная тема.

> А ведь он в чем-то прав.

Он прав, КАК ВСЕГДА.

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

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

Оригинал не читаем?

Линус несколько раз неприлично выругался о GCC, в том числе, из-за нелепого warning, когда имя локальной переменной совпадает с именем глобальной, например, index из <string.h>...

>Линус несколько раз неприлично выругался о GCC, в том числе, из-за нелепого warning, когда имя локальной переменной совпадает с именем глобальной, например, index из <string.h>...

А вот за такие "совпадения" надо сразу увольнять. Потому как если человек писал код и НЕ ПРОВЕРИЛ, а проще говоря, когда писал, не включил вывод предупреждений, то говорить о качестве кода не приходится.

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

>А вот за такие "совпадения" надо сразу увольнять. Потому как если > >человек писал код и НЕ ПРОВЕРИЛ, а проще говоря, когда писал, не >включил вывод предупреждений, то говорить о качестве кода не >приходится.

сам то что написал, чтоб кого-то увольнять

> Выяснилось, что автора патча -- Andrew Morton, Торвальдс был в огорчении :)

А кто автор исправляемого фрагмента?

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

* linux/drivers/ide/pci/serverworks.c Version 0.8 25 Ebr 2003
*
* Copyright (C) 1998-2000 Michel Aubry
* Copyright (C) 1998-2000 Andrzej Krzysztofowicz
* Copyright (C) 1998-2000 Andre Hedrick <andre@linux-ide.org>
* Portions copyright (c) 2001 Sun Microsystems

Код там действительно убойный

>сам то что написал, чтоб кого-то увольнять

Да, написал и немало. Еще вопросы?

>А вот за такие "совпадения" надо сразу увольнять.

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

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

>>Линус несколько раз неприлично выругался о GCC, в том числе, из-за нелепого warning, когда имя локальной переменной совпадает с именем глобальной, например, index из <string.h>... >А вот за такие "совпадения" надо сразу увольнять. Потому как если человек писал код и НЕ ПРОВЕРИЛ, а проще говоря, когда писал, не включил вывод предупреждений, то говорить о качестве кода не приходится.

Warning - он на то и warning, что он не error. А проще говоря компилятор предупреждает человека : "посмотри, здесь может быть потенциальная ошибка." А человек смотрит и понимает, что здесь ошибки быть не может - все верно. Или понимает, что действительно допустил промашку.

То есть программа с варнингами - вполне нормально, если программист их проанализировал и понял, что в этих местах все в порядке. Тем не менее отключать их не рекомендуется.

да да, еще на kerneltrap обсуждение кода serverworks.c было, рекомендую почитать тоже :)

>>из-за нелепого warning, когда имя локальной переменной совпадает с именем глобальной >А вот за такие "совпадения" надо сразу увольнять.

Вполне нормально, особенно с именем index. У тебя просто попросили убедиться, что ты тот index имел ввиду.

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

>ИМХО, это тянет на юнешеский максимализим :)

Нет. Это тянет на достаточный опыт разработки проектов в большом коллективе.

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

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

>И самое главно, что плохого в этом совпадении? Если область действия локальной переменной 3 строчки, зачем придумывать ей новое имя...

Затем что если область действия локальной переменной 3 строчки, ничто не мешает придумать неконфликтующее имя, а если область действия - несколько страниц кода, то подобное наплевательство - wide road to hell.

>То есть программа с варнингами - вполне нормально, если программист их проанализировал и понял, что в этих местах все в порядке. Тем не менее отключать их не рекомендуется.

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

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

int somevalue;

... ... /* Тут - под сотню строк кода */ ...

for (int i = 0; i < index; ++i) { int somevalue; /* !!! */ ... /* Тут еще какой-то код, работающий с somevalue */ }

Внимание, вопрос: int somevalue; /* !!! */ объявлено по ошибке и надо использовать предыдущую переменную или все так и должно быть? И кто об этом вспомнит через полгода?

> Подобный подход называется бардаком.

Вообще-то он называется базаром...

:-))

> предупреждение компилятора - это просто иной способ высказать мысль о том,
> что автор принимал тяжёлые наркотики, ... Это жирные предупреждения о некомпетентности!

А я вот, например, не считаю, что код типа

if (p = x)

должен выдавать предупреждение, а приведённый ниже - не должен

if ((p = x))

ИМХО, это _нормальный_ код, соответствующий стандарту. А если программист
не различает = и ==, то это его (программсита) проблемы.

>if (p = x)

>if ((p = x))

Можно узнать, ЗАЧЕМ писать подобное?

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

>> Можно узнать, ЗАЧЕМ писать подобное?

хорошо, напишем по-другому

while((p = func()))

{

...

}

>while((p = func()))

Ну и для чего это?

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

Написать 50 строк не составляет проблемы. Вот >5000 уже не каждый анонимус осилит :)

вы пидарасы, ничего не рубите в Си!

ты вообще программы то хоть раз писал?

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

Вообще, IMHO конечно, надо было приравнивание сделать ":=", и не было бы этой проблемы.

> для того, что _удобно_ это

Это удобно только упертым фонатам. То, что язык это позволяет - не значит, что так НУЖНО делать. Читаемость и понятность кода важнее "лнгвистических изысков", если вы работали в коллективе - вы это поймете. Конечно, если для вас программирование - это олимпиады по информатике, то вы правы :)

> А если программист не различает = и ==, то это его (программсита) проблемы.

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

Собственно, ворнинги и помогают ему, программисту, обнаружить и решить "его (программсита) проблемы".

> Затем что если область действия локальной переменной 3 строчки, ничто не мешает придумать неконфликтующее имя, а если область действия - несколько страниц кода, то подобное наплевательство - wide road to hell.

Тогда предлагаю ввести новый тип варнинга!

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

Сравни читаемость 2-х вариантов из реального кода:

	int rc;
--- 1-й -----------------------------------------------
    rc = video_device_create_file(vdev, &class_device_attr_stream_id);
	if (rc) goto err_stream_id;
	rc = video_device_create_file(vdev, &class_device_attr_model);
	if (rc) goto err_model;
	rc = video_device_create_file(vdev, &class_device_attr_pictsetting);
	if (rc) goto err_pictsetting;

	return 0;

err_pictsetting:
 	video_device_remove_file(vdev, &class_device_attr_model);
err_model:
 	video_device_remove_file(vdev, &class_device_attr_stream_id);
err_stream_id:
-----2-й----------------------------
     if(!(rc = video_device_create_file(vdev, &class_device_attr_stream_id))) { 
         if(!(rc = video_device_create_file(vdev, &class_device_attr_model))) {
            if((rc = video_device_create_file(vdev, &class_device_attr_pictsetting))) 
                video_device_remove_file(vdev, &class_device_attr_model);
         } else {
            video_device_remove_file(vdev, &class_device_attr_stream_id);
         }
     }
--------------------------------

PS: 2-й кстати отлично разбирается продвтнутыми IDE в отличае от 1-го 

> Вообще, IMHO конечно, надо было приравнивание сделать ":=", и не было бы этой проблемы.

Да, да, Линус уже говорил, что Pascal "лучше всех" (имелось в виду, конечно, стройнее всех) ;-)

Ну, это единственное, что можно было бы Си позаимствовать у Паскаля. :) И вообще, один оператор - это ещё не Паскаль.

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

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

Молодой человек, вы видели, как собирается хотя бы одна более-менее известная программа? ;) Я года три сижу на генте и заметил, что 99% всех прог собираются с предупреждениями. Кстати, недавно обновлял gcc, при сборке вылезла туева хуча warning'ов.. О_О

>Молодой человек, вы видели, как собирается хотя бы одна более-менее известная программа? ;) Я года три сижу на генте и заметил, что 99% всех прог собираются с предупреждениями. Кстати, недавно обновлял gcc, при сборке вылезла туева хуча warning'ов.. О_О

Молодой человек, я семь лет пишу на С++. Если "более-менее известная программа" программа собирается с предупреждениями, это не означает что эта программа - эталон и всем надо делать так.

И вообще, не надо путать _код_программы_ и _предоставляемую_функциональность_. У того же sendmail функциональности больше чем у всех других MTA, а о качестве кода лучше вообще не вспоминать.

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

Поэтому Линус прав: надо не прятать вывод warnings из отвратно написанного кода, а сам код менять, потому, что warnings в этом случае просто свидетельство кривого стиля программирования.

>Вот просто заменить само написание = на := и не более.

Упорная провока флейма Си vis Паскаль :) Ох, Торвальдса на вас не хватает :)) Заменит '=' на ':=', а == на .EQ. , а весь код переписать :)

> Упорная провока флейма Си vis Паскаль

Не, я за Си, это единственное, что мне в нём не нравится. :)

> == на .EQ.

Это лишнее. :)

> весь код переписать :)

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

> Это удобно только упертым фонатам. То, что язык это позволяет - не значит, что так НУЖНО делать. Читаемость и понятность кода важнее "лнгвистических изысков", если вы работали в коллективе - вы это поймете. Конечно, если для вас программирование - это олимпиады по информатике, то вы правы :)

Что лучше читается?

(1)
if ((pid = fork()) != 0)
{
...
}
else
{
...
}

или
(2)
pid = fork();
if (pid != 0)
{
...
}
else
{
...
}

мне (1) как--то милее

>Молодой человек, я семь лет пишу на С++. Если "более-менее известная программа" программа собирается с предупреждениями, это не означает что эта программа - эталон и всем надо делать так.

Однако почему же при компиляции почти во всех прог самого разного пошиба возникают предупреждения? М.б. потому, что в большинстве случаев их просто невозможно избежать? ;)