Отличный урок не только для учёных, но и для программистов. Многие программисты не хотят проводить эксперимент, потому что им кажется, что они заранее знают ответ. Особенно это ярко видно в вопросах производительности. Нередко можно услышать доводы вроде: "Очевидно, что метод X быстрее метода Y, ведь тут не создаётся два лишних объекта". А проведёшь должным образом измерительный эксперимент и окажется, что всё наоборот (к примеру, потому что компилятор умён и смог избежать создания объектов).
Интересно, спасибо! Я на таких условиях пропускаю DFA справа налево, и если он находит истинные операнды, которые не являются таковыми сами по себе, то это подозрительно. Но это работает только для условий без сайд-эффектов, в том числе потенциальных исключений, поэтому действительно все случаи не поймаешь.
Ангуляр никогда не трогал, но мой опыт подсказывает, что даже для какой-нибудь маленькой библиотеки можно написать статические правила, которые уберегут вас от ошибочных или неоптимальных использований. А уж Ангуляр-то совсем немаленькая штука.
В IntelliJ IDEA вижу одну инспекцию: Angular|Empty Event Handler. Что бы это ни значило.
А ещё нажав Ctrl+Shift+P два раза на выражении, можно увидеть статически выведенный диапазон значений:
Правда он не настолько умён, чтобы по контексту догадаться выводить в хексах. Но таким образом иногда можно отдебажить варнинг и понять, что собственно произошло.
Все эти фичи есть в бесплатной версии IDEA Community :-)
В Идейке (правда только для Джавы, видимо) и подсветка скобок не нужна, варнинги будут сразу в редакторе при вводе текста. У нас это онлайн-анализатор ловит:
Любопытно, кстати, что PVS-Studio анализирует недостижимый код. Мы, например, не выдаём предупреждение, что ch <= 0x0FF3A всегда истинно, потому что оно вообще недостижимо. Видимо, когда PVS-Studio находит всегда ложное условие, оно выдаёт на него варнинг и считает, что этого условия нету и продолжает анализ дальше?
Он вроде выключен по дефолту. Попробуй включить:
А вроде в Идейке и так есть миграция с JUnit4 на JUnit5. Смотрите прошлогодний блогпост, например: https://blog.jetbrains.com/idea/2017/11/intellij-idea-2017-3-junit-support/
Интересно, зачем потребовалось для этого свой плагин писать.
Звучит будто он работает в Twitter, хотя видимо это не так.
Дожили! В JugRu теперь платят людям, чтобы они ругали Котлин!
Отличный урок не только для учёных, но и для программистов. Многие программисты не хотят проводить эксперимент, потому что им кажется, что они заранее знают ответ. Особенно это ярко видно в вопросах производительности. Нередко можно услышать доводы вроде: "Очевидно, что метод X быстрее метода Y, ведь тут не создаётся два лишних объекта". А проведёшь должным образом измерительный эксперимент и окажется, что всё наоборот (к примеру, потому что компилятор умён и смог избежать создания объектов).
Интересно, спасибо! Я на таких условиях пропускаю DFA справа налево, и если он находит истинные операнды, которые не являются таковыми сами по себе, то это подозрительно. Но это работает только для условий без сайд-эффектов, в том числе потенциальных исключений, поэтому действительно все случаи не поймаешь.
То что в целом работают — это я знаю :-) Меня конкретно делитель интересовал. У нас такой нет. Видимо пока делать не будем. Спасибо за ответ!
То есть у вас есть специальная аннотация "параметр используется как делитель"? И часто реальную пользу это приносило?
Интересно, а это у вас pattern-based или dataflow?
Можно и попроще вроде
someStream().map(condition).reduce(Boolean::logicalOr).orElse(true). Только это всё без короткого замыкания, что печально.Ты так говоришь "например", будто есть какая-то другая польза :-)
Ангуляр никогда не трогал, но мой опыт подсказывает, что даже для какой-нибудь маленькой библиотеки можно написать статические правила, которые уберегут вас от ошибочных или неоптимальных использований. А уж Ангуляр-то совсем немаленькая штука.
В IntelliJ IDEA вижу одну инспекцию: Angular|Empty Event Handler. Что бы это ни значило.
Главное не распространить это на битовый сдвиг, который у многих ассоциируется с умножением и делением, а приоритет его ниже сложения.
Абсолютно согласен. А ещё тыща задачек с сайд-эффектом в map (хоть в стримах, хоть в Котлине). Фантазия у некоторых компаний подкачала.
Менять не надо, если откровенно путающих ситуаций не возникает, согласен.
А если наоборот,
!a && a && *a == 2А ещё нажав Ctrl+Shift+P два раза на выражении, можно увидеть статически выведенный диапазон значений:
Правда он не настолько умён, чтобы по контексту догадаться выводить в хексах. Но таким образом иногда можно отдебажить варнинг и понять, что собственно произошло.
Все эти фичи есть в бесплатной версии IDEA Community :-)
В Идейке (правда только для Джавы, видимо) и подсветка скобок не нужна, варнинги будут сразу в редакторе при вводе текста. У нас это онлайн-анализатор ловит:
Любопытно, кстати, что PVS-Studio анализирует недостижимый код. Мы, например, не выдаём предупреждение, что
ch <= 0x0FF3Aвсегда истинно, потому что оно вообще недостижимо. Видимо, когда PVS-Studio находит всегда ложное условие, оно выдаёт на него варнинг и считает, что этого условия нету и продолжает анализ дальше?Что-то у вас одни белые мужчины в ПК. А как же diversity?!
habr.com/company/jugru/blog Только там рыться надо, потому что они тонну всего помимо этого публикуют. Вот, например, из недавнего habr.com/company/jugru/blog/424763