Нет, не отключаем. Думаю, дело в том, что мы сильно толще вас. У нас только в мастер community 500 коммитов в неделю. А если ещё закрытая часть, которая не меньше. Представьте, что я улучшаю инспекцию, и она находит не одно или два, а сто новых подозрительных мест в коде. Это, кстати, не предел, мой личный рекорд — 800 новых предупреждений (речь о инспекциях категории Probable bugs, а не о каких-нибудь стилистических). Причём исправлять их надо вдумчиво, автоматом не получится. И что, бросать всё и начинать править? Часто проблемы находятся в коде пятнадцатилетней давности, который относится к поддержке какого-нибудь устаревшего фреймворка, у которого полтора пользователя теперь, и никто особо не в курсе даже что надо сделать в Идейке, чтобы метод с новым предупреждением выполнился. Да, можно тратить силы на это, но кажется, что можно потратить их более рационально.
Ещё бывает, что мы импортируем кодовую базу. Например, кто-то разрабатывал плагин независимо, а потом мы договорились с автором, устроили его на работу и вставили его код к себе. Возможно, в нём немало предупреждений статического анализатора. Стоит ли в первую очередь их вычищать? Непонятно.
Ну и, к сожалению, местами просто не хватает культуры. Я не коммичу код с новыми варнингами и стараюсь исправлять варнинги в любом коде, который трогаю. Но не все так делают, и это не форсируется у нас. Последнее время мы стали исправлять ситуацию. Некоторые инспекции у нас включены в так называемый список Zero tolerance inspections. Предупреждения от этих инспекций рисуются у нас кроваво-красным цветом, их сложно игнорировать. А если код с таким предупреждением закоммитить, то падает один из билдов, мне приходит письмо, и я с этим разбираюсь. Постепенно мы увеличиваем список таких инспекций, но, конечно, до идеала далеко. В частности, например, сообщений вида condition is always true пока слишком много, чтобы вот так легко их все исправить.
Да, тут напрашивается ответ, конечно :-) Во-первых, поздравляю вас с релизом, вы молодцы и делаете нужное дело. Пройдёмся по предупреждениям
return capitalized / words.size() < 0.2;
Это наглядный пример, что конкуренция — двигатель прогресса! Я заметил во время бета-тестирования, что вы тут умнее нас. Но очевидно, это не ваше достоинство, а наша недоработка :-) Я сообщил ответственному человеку, и тот уже исправил, в следующей версии будем это репортить.
for (int index = count - 1; index >= 0; index++) {
Мы знаем, что count в этом месте положительный и count - 1 неотрицательный. Кстати, в этом можно убедиться, нажав в IDE два раза Ctrl+Shift+P:
Однако наш dataflow аккуратно вычисляет все переполнения и не считает, что условие цикла всегда истинно, потому что это не так.
Зато недавно мы сделали другую инспекцию, которая здесь срабатывает. В принципе никакой разницы нет, с какого значения мы начинаем этот цикл, главное — это связка операторов в условии и инкременте. Связки >/++ и </-- — это почти всегда баги, о которых и сообщает новая инспекция. Будет в следующей версии. Так что эту проблему мы находим, хоть и по-другому.
LoadingOrder.BEFORE_STR_OLD.equalsIgnoreCase(str) || и следующая
Эта инспекция почему-то выключена по умолчанию. Надо будет разобраться с этим. Если работает нормально, то включим.
for (int i = offset; i < endOffset; i++)
Это мы видим, да. Но исправить всем лень. И, кстати, вы правы, я смог сломать Идейку, вызвав исключение в этом месте! Если кому интересно, надо в конце файла набрать
/**
* <p><
Встать курсором между >< и нажать Enter! Если вы это повторите, у вас замигает в правом нижнем углу восклицательный знак. Report to JetBrains нажимать необязательно, мы уже в курсе :-) Вот, кстати, вам хороший пример пользы от статического анализа. Теперь-то исправим.
if (buffer.length() > 0) {
Это видим тоже. Не очень давно, кстати, может с прошлой версии. Думаю, в данном случае это действительно просто лишняя проверка.
Собственно, если кто-то из них займётся этим в свободное время, то мы не против и желаем им удачи. Главное только, чтобы это их от основной работы не отвлекало :)
Мне кажется, это странный подход. Во-первых, если ваш сотрудник найдёт реальный баг и получит баунти, это хороший маркетинговый результат. Одно дело теоретическая возможность, а другое — реальная проблема, которую авторы продукта посчитали достаточно значимой, чтобы оплатить. Этим вполне можно хвастаться. А во-вторых, это тестирование. Проверяя новые проекты всегда находишь, что бы улучшить в анализаторе. Где-то видишь ложную сработку и понимаешь, что её можно исключить статически. Где-то сработка нормальная, но сообщение о баге можно улучшить. Где-то вместо двух варнингов разумно выдать один, чтобы уменьшить количество шума. Поэтому мне кажется вполне допустимым, если сотрудники долю рабочего времени (например, до десяти процентов) тратить на поиск багов в проектах, возможно даже получая за это вознаграждение. Относитесь к этому как владелец ресторана относится к чаевым, которые получают официанты.
Так вроде вся суть же в красивом выводе, разве нет? Если красивый вывод не нужен, Java-версия assertTrue(foo(input).contains(output)) ничуть не отличается от питоновской. Ну окей, я понял, что вас тошнит от скобок, Лисп не для вас. Окей, понял, что вас тошнит от camelCase. Но эти аргументы не претендуют на объективность.
Философский вопрос — называть ли программой на языке Питон то, что вы пишете и что потом препроцессируется, чтобы сгенерировать реальную программу, которая уже подаётся на вход компилятору. По сути дела это некоторый мета-язык, лишь похожий на Питон синтаксически, но имеющий другую семантику. Разумеется, можно и для Джавы сделать препроцессор, имеются всякие кодогенераторы, но вроде как смысла нет. Если совсем припекает, можно воспользоваться другим JVM-языком, к примеру, Груви, где такие структуры вполне возможны. Смесь Груви и Джавы в одном проекте вполне легко устроить (мы это делаем). И по крайней мере вы пишете на конкретном языке, с конкретным синтаксисом и семантикой, а не непонятно на чём, что препроцессируется в Питон.
Это статически известно на этапе компиляции, можно всегда посмотреть в IDE или javadoc. Можно контролировать типы, например, выносом интерфейсов API в отдельный модуль с особыми правилами внесения изменений. Изменить тип можно только изменением декларации, никакое изменение тела метода тип не поменяет. Да, возможны редкие случаи, когда изменение типа метода не сломает весь остальной код, но это вполне нормально. В динамическом языке изменение тела одного метода может повлиять на результат других (которые делегируют к этому). Если делегация условная, другой метод может после такого изменения неожиданно возвращать разные типы в разных ситуациях. Я не понимаю, как можно уверенно рефакторить проект на динамическом языке, не обложившись тестами на типы аргументов и результатов методов.
Это старичкам трудно. Мы пишем с сарказмом, а новички не понимают, хотя и для вас тоже пишем. Видимо, надо прямее мысли излагать, но в старости мы уже не можем :-(
Ну так нулл один, и действительно разумно ожидать, что его не возвращают. А типов много, и тогда разумно ожидать что? Методов, возвращающих строки, должно быть очень мало. Вот метод getName() вернёт строку или объект Name? Неочевидно, чего ожидать.
В текущем проекте мы используем аннотации вроде @NotNull и annotation processor, который превращает их в рантайм-проверки. Это эффективно решает проблему и избавляет от необходимости проверять на нуллы. Но вы ткнули в больное место, конечно, за это плюсик!
А холивара ради можно вот что обсудить. Я утверждаю, что чтобы протестировать API на динамически типизированном языке, вам потребуется вдвое больше кода. Потому что надо проверить, что каждый метод возвращает результат нужного типа и кидает исключение (или иным способом сигнализирует об ошибке) на параметры некорректных типов. То что в языках вроде Java проверяется компилятором и требует ноль тестов, в Питоне выродится в ужасный бойлерплейт. Как вы решаете эту проблему?
Вы же шутите, да? Вы же взрослый человек и понимаете, что это дело привычки, а семантика одна и та же выражается. Это всё равно что говорить, мол русский язык уродливо выглядит, все эти "Я тебя люблю", то ли дело английское "I love you".
Нет, не отключаем. Думаю, дело в том, что мы сильно толще вас. У нас только в мастер community 500 коммитов в неделю. А если ещё закрытая часть, которая не меньше. Представьте, что я улучшаю инспекцию, и она находит не одно или два, а сто новых подозрительных мест в коде. Это, кстати, не предел, мой личный рекорд — 800 новых предупреждений (речь о инспекциях категории Probable bugs, а не о каких-нибудь стилистических). Причём исправлять их надо вдумчиво, автоматом не получится. И что, бросать всё и начинать править? Часто проблемы находятся в коде пятнадцатилетней давности, который относится к поддержке какого-нибудь устаревшего фреймворка, у которого полтора пользователя теперь, и никто особо не в курсе даже что надо сделать в Идейке, чтобы метод с новым предупреждением выполнился. Да, можно тратить силы на это, но кажется, что можно потратить их более рационально.
Ещё бывает, что мы импортируем кодовую базу. Например, кто-то разрабатывал плагин независимо, а потом мы договорились с автором, устроили его на работу и вставили его код к себе. Возможно, в нём немало предупреждений статического анализатора. Стоит ли в первую очередь их вычищать? Непонятно.
Ну и, к сожалению, местами просто не хватает культуры. Я не коммичу код с новыми варнингами и стараюсь исправлять варнинги в любом коде, который трогаю. Но не все так делают, и это не форсируется у нас. Последнее время мы стали исправлять ситуацию. Некоторые инспекции у нас включены в так называемый список Zero tolerance inspections. Предупреждения от этих инспекций рисуются у нас кроваво-красным цветом, их сложно игнорировать. А если код с таким предупреждением закоммитить, то падает один из билдов, мне приходит письмо, и я с этим разбираюсь. Постепенно мы увеличиваем список таких инспекций, но, конечно, до идеала далеко. В частности, например, сообщений вида condition is always true пока слишком много, чтобы вот так легко их все исправить.
Да, тут напрашивается ответ, конечно :-) Во-первых, поздравляю вас с релизом, вы молодцы и делаете нужное дело. Пройдёмся по предупреждениям
Это наглядный пример, что конкуренция — двигатель прогресса! Я заметил во время бета-тестирования, что вы тут умнее нас. Но очевидно, это не ваше достоинство, а наша недоработка :-) Я сообщил ответственному человеку, и тот уже исправил, в следующей версии будем это репортить.
Мы знаем, что
countв этом месте положительный иcount - 1неотрицательный. Кстати, в этом можно убедиться, нажав в IDE два раза Ctrl+Shift+P:Однако наш dataflow аккуратно вычисляет все переполнения и не считает, что условие цикла всегда истинно, потому что это не так.
Зато недавно мы сделали другую инспекцию, которая здесь срабатывает. В принципе никакой разницы нет, с какого значения мы начинаем этот цикл, главное — это связка операторов в условии и инкременте. Связки
>/++и</--— это почти всегда баги, о которых и сообщает новая инспекция. Будет в следующей версии. Так что эту проблему мы находим, хоть и по-другому.Эта инспекция почему-то выключена по умолчанию. Надо будет разобраться с этим. Если работает нормально, то включим.
Это мы видим, да. Но исправить всем лень. И, кстати, вы правы, я смог сломать Идейку, вызвав исключение в этом месте! Если кому интересно, надо в конце файла набрать
Встать курсором между
><и нажать Enter! Если вы это повторите, у вас замигает в правом нижнем углу восклицательный знак. Report to JetBrains нажимать необязательно, мы уже в курсе :-) Вот, кстати, вам хороший пример пользы от статического анализа. Теперь-то исправим.Это видим тоже. Не очень давно, кстати, может с прошлой версии. Думаю, в данном случае это действительно просто лишняя проверка.
Вот это прям очень круто было. Если у вас dataflow это выводит, а не паттерн, то поднимаю лапки и признаюсь, что нам такое слабо пока.
Это место я прекрасно помню. Очень радовался больше года назад, когда научил Идейку его находить. А исправить что-то всем лень. Надо заняться, да.
Мне кажется, это странный подход. Во-первых, если ваш сотрудник найдёт реальный баг и получит баунти, это хороший маркетинговый результат. Одно дело теоретическая возможность, а другое — реальная проблема, которую авторы продукта посчитали достаточно значимой, чтобы оплатить. Этим вполне можно хвастаться. А во-вторых, это тестирование. Проверяя новые проекты всегда находишь, что бы улучшить в анализаторе. Где-то видишь ложную сработку и понимаешь, что её можно исключить статически. Где-то сработка нормальная, но сообщение о баге можно улучшить. Где-то вместо двух варнингов разумно выдать один, чтобы уменьшить количество шума. Поэтому мне кажется вполне допустимым, если сотрудники долю рабочего времени (например, до десяти процентов) тратить на поиск багов в проектах, возможно даже получая за это вознаграждение. Относитесь к этому как владелец ресторана относится к чаевым, которые получают официанты.
Joker был в Питере, а не в Москве :-) Рад, что вам понравились наши паззлеры. Приезжайте в Новосибирск на CodeFest!
Слева кабель-каналы на стене, уродство. Справа они наверняка спрятаны в стену. Это хорошо.
Не особо.
Так вроде вся суть же в красивом выводе, разве нет? Если красивый вывод не нужен, Java-версия
assertTrue(foo(input).contains(output))ничуть не отличается от питоновской. Ну окей, я понял, что вас тошнит от скобок, Лисп не для вас. Окей, понял, что вас тошнит от camelCase. Но эти аргументы не претендуют на объективность.Про покрытие неоднократно упоминал в статье.
Это статически известно на этапе компиляции, можно всегда посмотреть в IDE или javadoc. Можно контролировать типы, например, выносом интерфейсов API в отдельный модуль с особыми правилами внесения изменений. Изменить тип можно только изменением декларации, никакое изменение тела метода тип не поменяет. Да, возможны редкие случаи, когда изменение типа метода не сломает весь остальной код, но это вполне нормально. В динамическом языке изменение тела одного метода может повлиять на результат других (которые делегируют к этому). Если делегация условная, другой метод может после такого изменения неожиданно возвращать разные типы в разных ситуациях. Я не понимаю, как можно уверенно рефакторить проект на динамическом языке, не обложившись тестами на типы аргументов и результатов методов.
Это старичкам трудно. Мы пишем с сарказмом, а новички не понимают, хотя и для вас тоже пишем. Видимо, надо прямее мысли излагать, но в старости мы уже не можем :-(
Убирайте, конечно, я только за!
Ну так нулл один, и действительно разумно ожидать, что его не возвращают. А типов много, и тогда разумно ожидать что? Методов, возвращающих строки, должно быть очень мало. Вот метод getName() вернёт строку или объект Name? Неочевидно, чего ожидать.
В текущем проекте мы используем аннотации вроде
@NotNullи annotation processor, который превращает их в рантайм-проверки. Это эффективно решает проблему и избавляет от необходимости проверять на нуллы. Но вы ткнули в больное место, конечно, за это плюсик!А холивара ради можно вот что обсудить. Я утверждаю, что чтобы протестировать API на динамически типизированном языке, вам потребуется вдвое больше кода. Потому что надо проверить, что каждый метод возвращает результат нужного типа и кидает исключение (или иным способом сигнализирует об ошибке) на параметры некорректных типов. То что в языках вроде Java проверяется компилятором и требует ноль тестов, в Питоне выродится в ужасный бойлерплейт. Как вы решаете эту проблему?
Вы же шутите, да? Вы же взрослый человек и понимаете, что это дело привычки, а семантика одна и та же выражается. Это всё равно что говорить, мол русский язык уродливо выглядит, все эти "Я тебя люблю", то ли дело английское "I love you".
Это правильно, хотя не всегда удаётся настроить так, чтобы работало хорошо и быстро и не раздражало. Но надо стремиться, конечно.
Поправил вам длину столбиков на картинке. Не благодарите.
