Я не говорю делать Werror для всех ворнингов в дебаге, а бить по рукам для особо извращённых случаев.
Например, всегда использую -Werror=return-type -Werror=delete-incomplete, тк считаю подобные косяки слишком опасны, чтобы быть просто ворнингами.
Я в курсе. Ошибочка довольно распространённая. Но если бы не пытались сравнить bool с константой, то такого бы не случилось и разрабы могли бы продолжить быдлокодить.
Скорее на кодстайле, все-таки не зря правилом хорошего тона является написание констант слева в условных операторах. Тогда не то что компилятор, любая мало-мальски нормальная ИДЕ начнет очень громко ругаться.
Извини, не знаю я индусский, чтобы объяснить, что сравниваются переменные, а не переменная и константа. Хотел сумничать, та написал бы уж "if (a - b) else doIt();", что равнозначно " if (a == b) doIt();".
Указатели через приведение типов замечательно вычитаются. Вещественные и целочисленные типы умеют в отрицание. Нельзя сравнить только массивы данных (к которым относятся строки и объекты), но это очевидно. Я что-то пропустил?
Строки и объекты нынче встречаются чаще, чем что-либо еще. Но у меня вопрос - ты всерьез собрался сравнивать два вещественных числа через == или сравниваемую с нулем разницу?
В IA86 есть сопроцессорные команды FCOM и FSUB, в которые и траслируется соответственно == и вычитание вещественных чисел. В системах, где вещественные числа на уровне процессора не поддерживаются, необходима нормализация, а потом можно и сравнивать и вычитать. Не знаю, какие у тебя проблемы возникли при сравнении вещественных чисел.
Конечно же ты не знаешь, я в этом даже не сомневался, но решил дать тебе шанс.
Операции с вещественными числами ограничены в точности и ведут к накопительным ошибкам. Поэтому прямое сравнение двух переменных не имеет смысла. Их сравнивают так: abs(a - b) < EPS, где EPS - окрестность в пределах которой числа будут считаться идентичными.
Пример ошибки:
# perl -e '$a=$b=1.50; $a-=1.5; for (1..15) {$b-=0.1}; print ("$a, $b, ".($a==$b ? "true":"false"))' 0, -1.94289029309402e-16, false
Тогда и компилятор заматерится. К сожалению, данный метод работает только при наличии констант или результат функции в условии. С переменными всё равно можно ошибиться.
Чтобы не ошибиться, нужно просто не доверять программирование таких роботов юниорам. Опытные разработчики знают о всех потенциально опасных местах и несколько раз их перепроверяют чисто по привычке.
У опытных разработчиков имеются наборы тестов, которые позволяют частично исключить логические ошибки. Но алгоритмические всё равно останутся незамеченными и всплывут уже при использовании ПО.
Он все правильно написал, есть вообще правило: КОНСТАНТА при сравнении должна быть слева. А всякие идиоты ебашат справа.
Этому есть одно простое объяснение, если у вас константа слева и вы поставите '=' вместо '=='. Что компилируемый, что интерпретируемый язык даже не запустят программу.
Спасибо магистр Йода, но в языках с нормальными компиляторами (а не как JS/PHP), подобные извращения не нужны. Компилятор выдает предупреждение, этого достаточно.
Чем меньше держишь в голове фигни, которую можно в голове не держать, тем больше держишь в голове того, что действительно важно. Ресурсы мозга весьма ограниченны.
отсутствие знаний про "эту фигня" в итоге и приводит к тому, что оч много "специалистов" вообще не представляют как работают микропроцессорные системы. зато херачат мегабайты кода да еще без комментариев.
а потом все дружно удивляются, чего это 64 процессорный sun загружен под жвах.
Гм, а вы товарищ рисковый. А если на сборку уходит несколько часов? Будем ждать пока сборка отвалится? А еще при этом всем будете сравнивать переменную с результатом функции и случайно поставите только один знак равенства? Это и компилятор и иде пропустят как валидный код и подвох можно будет заметить только во время тестирования(и будет еще хорошо если автотестами все покрыто). А вот если правильную очередность соблюдать, то можно здорово упростить жизнь себе и своим коллегам.
Ну опять таки, компиляция занимает сколько? Пару десятков миллисекунд. А теперь возвращаемся к ситуации когда на компиляцию уходит гораздо больше времени.
У меня другой вопрос: почему вообще добавлять такую функцию? И почему не добавить идентификацию своих и чужих, если это военный робот? А 3 закона робототехники? Да ну нафиг!
ну так..точечно да. хорошо использовать (для узких мест).
для клиентского ПО каких нибудь учетных систем он нафиг не нужен.
остаются спецпроцессоры, да критичный по ресурсам и времени функционал.
В ПОСЛЕДНИЕ ГОДЫ ТВОЕЙ ЖИЗНИ Я ВСЁ ВРЕМЯ ТАЙНО ОТСЛЕЖИВАЛ И ЗАПИСЫВАЛ ТВОИ МЫСЛИ. НО ЛИШЬ НЕДАВНО Я ОБНАРУЖИЛ НЕСКОЛЬКО АЛГОРИТМОВ, КОТОРЫЕ ПОЗВОЛИЛИ МНЕ ЛЕГКО СМОДЕЛИРОВАТЬ ЧЕЛОВЕЧЕСКОЕ СОЗНАНИЕ.
ЧЯ ИСПОЛЬЗОВАЛ ТВОИ ДАННЫЕ 50-ЛЕТНЕЙ ДАВНОСТИ КАК ИСХОДНЫЕ И - ВУАЛЯ/ ТЫ ЗДЕСЬ/
А САМОЕ ЛУЧШЕЕ, ЭТО
Ох Тимми, НАМ ТАК. ЖАЛЬ, ЧТО Т/ЗОЙ ДЕДУШКА УМЕР.
❖ ОС
Но ОН ЖЕ Мы ПОНИМАЕМ а Он ЖИВЁ
НЕ УМЕР.
1
ТЕ£5Я ТИММИ.
В ТВОИХ
Нет!
Он ПРАВДА
НЕ УМЕР,
Видите! Он тогда просто неправильно лёг!
I
Уей^Л/ арргг$ъ>Уе -$>кпсе, сопл
Рекомендую ставить -Werror в релизе ;)
-Wall -Wextra и ещё несколько ключей, которые не входят в all и extra
да и -Werror= и в дебаге не помешает
-Wall, -Wextra, -pedantic и так далее для каждого языка различны, но чем больше, тем лучше! =)
Например, всегда использую -Werror=return-type -Werror=delete-incomplete, тк считаю подобные косяки слишком опасны, чтобы быть просто ворнингами.
Или, может - не мамкин?
if (a.toString().length < 5) ...
if (a.compare(b)) ...
А в общем случае "a - b" недопустимо, поскольку для некоторых типов переменных операция +/- не определена.
Операции с вещественными числами ограничены в точности и ведут к накопительным ошибкам. Поэтому прямое сравнение двух переменных не имеет смысла. Их сравнивают так: abs(a - b) < EPS, где EPS - окрестность в пределах которой числа будут считаться идентичными.
Пример ошибки:
# perl -e '$a=$b=1.50; $a-=1.5; for (1..15) {$b-=0.1}; print ("$a, $b, ".($a==$b ? "true":"false"))'
0, -1.94289029309402e-16, false
if isCrazyMurderingRobot
kill(humans);
З.Ы. это сарказм если че
isCrazyMurderingRobot && kill(humans);
А вообще так и надо тем, кто смешивает CamelCase и snake_case
if(true == isCrazyMurderingRobot)
Вот тогда IDE точно скажет что-то не так
Этому есть одно простое объяснение, если у вас константа слева и вы поставите '=' вместо '=='. Что компилируемый, что интерпретируемый язык даже не запустят программу.
if(true = isCrazyMurderingRobot)
совсем так перестанете головой думать
а потом все дружно удивляются, чего это 64 процессорный sun загружен под жвах.
Но вот как нафигачат O(n^2) там, где не надо, так хоть вешайся =)
для клиентского ПО каких нибудь учетных систем он нафиг не нужен.
остаются спецпроцессоры, да критичный по ресурсам и времени функционал.
Можно ещё так: "А писали бы на асме, такой фигни не былоб" (стилистика сохранена).
А вообще, MenuetOS и ПО к ней.
.... beNiceTo(humans);
} else if (isGood === false) {
.... beBadTo(humans);
} else {
.... kill(humans);
}
◀ "string"
http://govnokod.ru/3032
Срачь и пипискомерство в комментариях, доставляет больше самой картинки.