• Кто умнее чем IDEA?
    0

    Да, есть инспекции, а есть аннотаторы, и в некоторых языках почему-то используют аннотаторы, к которым по умолчанию нет механизма саппресса. Почему это так — для меня загадка. В джаве мы всё делаем инспекциями. Но если вы считаете, что у вас что-то подсвечивается неправильно, всегда можно написать баг-репорт или проголосовать за существующих. Про вашу проблему есть репорт?

  • Кто умнее чем IDEA?
    +6

    В джаве return; посреди метода — это не предупреждение, а ошибка компиляции. Если вы совсем не хотите никаких ошибок видеть, а только подсветку синтаксиса, можно отключить гектора в статусной строке:



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


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


    Кстати, вот вы написали if (true && ...), а ведь это бесполезно. Вы хотели сделать ветку всегда истинной, но в итоге не сделали ничего. Надо было написать if (true || ...). Если вы эту ошибку сделали в редакторе Хабра, вы могли её сделать и в редакторе кода без встроенного статического анализатора. А анализатор подсветит по-разному: в первом случае выделит только true, а во втором — всё условие. Опытный пользователь сразу заметит ошибку, даже если использует подобные условия для прототипирования. В любом случае это полезная визуальная напоминалка, что эта ветка выполнится всегда. Она пригодится при отладке.


    Ещё кстати в отладчике можно менять значения переменных, форсируя выполнение определённой ветки. Часто это гораздо удобнее, чем модифицировать код.

  • Кто умнее чем IDEA?
    +2

    Вообще в этом случае мы всё равно по умолчанию ничего не напишем. Мы не предупреждаем обо всех возможных ошибках с nullability, иначе у вас бы был миллион мусорных предупреждений. Мы говорим только о вероятных ошибках. Про элемент массива мы бы сказали, если бы он был объявлен как @Nullable DriverPropertyInfo @Nullable [], то есть элементы были бы тоже аннотированы как Nullable.

  • Кто умнее чем IDEA?
    +1

    Спасибо за баг-репорт. Это новая фича in-place refactoring пока не отлажена, в 2020.1 EAP ещё часто падает. В 2019.3 таких проблем нет.

  • Вещи, которые вы [возможно] не знали о Java
    0

    Этой фиче сто лет в обед.

  • Когда я на часах
    +1

    Только сейчас понял, что там ещё и QR-код палит :-)

  • Когда я на часах
    0

    Стоило просто обрезать верх и низ окна :-)

  • Вещи, которые вы [возможно] не знали о Java
    +1

    Кстати, IntelliJ IDEA умеет переписать за вас свитч по классам. Так что смело свитчуйтесь по любым объектам, IDEA всё поправит:



    Результат:


    if (String.class.equals(clazz)) {
        return "str";
    } else if (Integer.class.equals(clazz)) {
        return "int";
    }
    return "obj";
  • Топ лучших докладов Joker 2019
    +1

    Всё то вы про меня знаете. Иногда бывает надо куда-нибудь съездить.

  • Топ лучших докладов Joker 2019
    +6

    Насчёт было мало. Docker/Kuber/DevOps — это конфа DevOops, которую проводили почти сразу после Джокера те же люди. Вроде эти вещи напрямую с джавой не связаны, надо идти на более профильные конференции. Для Machine learning, кажется, тоже что-то более профильное есть.

  • Топ лучших докладов Joker 2019
    +7

    Сегодня не рулил, пешком ходил.

  • Многозадачный и любопытный. Java Champion Митя Александров о создании IT-комьюнити, «удаленке» и жизни
    +2

    Митя — прекрасный программист и отличный товарищ!

  • Лучшие плагины IntelliJ IDEA
    0

    Вообще подобные штуки есть. Например, XML-файлы имеют стандартную XML-расцветку по умолчанию, но если это Ant build.xml или, например, plugin.xml из плагина к Идее, то это распознаётся, иконка меняется, дополнительные инспекции и возможности появляются.

  • Тагир и Егор: интервью с Тагиром Валеевым
    0

    Вечно у тебя всё в мрачном свете! То шрифт плохой, то Идея глючит, то Тагир катится по наклонной!

  • Тагир и Егор: интервью с Тагиром Валеевым
    +2

    Легко отвечу здесь: когда вы напишете плагин, тогда и появится.

  • Тагир и Егор: интервью с Тагиром Валеевым
    +2

    Думаешь, мы подрались бы? Вряд ли :-)

  • Уходя уходи: почему не стоит принимать контроффер
    +1

    Я считаю, что есть компании лучше, чем FAANG. И, конечно, если ты работаешь не в самой идеальной компании, это не повод что-то менять. Изменения всегда имеют цену и совершенно не факт, что выгода от изменений превысит эту цену. Наконец, в человеческом мире ни цену, ни выгоду нормально не измеришь не только заранее, но и постфактум. Остаётся лишь гадать. Иногда лучше не гадать, а сидеть на попе ровно. На идеальной работе свет клином не сошёлся, в мире есть много других интересных дел, куда можно направить свою энергию. Возможно, вы из тех людей, которым карьера важнее всего. Но не все люди таковы, и обобщать не следует.

  • Уходя уходи: почему не стоит принимать контроффер
    0

    Верно, на структуру зарплаты (сколько оклад, сколько премия) обязательно обращать внимание при устройстве на работу. По-хорошему это должно быть прописано в изначальном оффере.

  • Использование машинного обучения в статическом анализе исходного кода программ
    +2

    Интересненько, хоть и много букв.


    Я думаю, ML не должен заменять традиционный статический анализ, а должен усиливать его слабые стороны. Слабые стороны — это эвристические инспекции. Иногда нормально не заскриптуешь ошибочную ситуацию и абстрактной интерпретацией её не решишь. Например, пользователь в коде обработки графики передаёт в какой-то метод x там, где параметр называется y, и наоборот. Выглядит подозрительно. Давайте ругаться, если имя формального параметра y, а фактически передаётся переменная с именем x (или x1, или xx, или boundX). Окей, работает, нашли пару багов. Релизнули, пользователи начали жаловаться:


    System.out.println(y);

    Собака, метод PrintStream#println почему-то обозначил свой параметр буквой x! Добавляем исключение. Далее видим такой код:


    return new Point(y, -x);

    Здесь речь действительно о координатах, и действительно где ожидается x, передаётся y. Вот только полный код:


    if(rotate90DegreesClockwise) {
      return new Point(y, -x);
    }

    Понятно, что никакой ошибки нет. И так далее. Получается очень хрупкая инспекция, у которой большой процент FP/FN и нужно скриптовать кучу случаев. Причём часто вокруг не стандартные методы API, а какие-то сторонние библиотеки или вообще классы пользовательского приложения. И это только про перепутанные x и y, а можно ведь и многие другие имена путать. В таких случаях, мне кажется, натравить ML на кодовую базу, чтобы моделька обучилась с учётом контекста какие комбинации формального и фактического параметра верные, а какие ошибочные, было бы вполне разумно.

  • Уходя уходи: почему не стоит принимать контроффер
    +10

    Либо не замираешь, с компанией ничего не происходит, а если происходит, находишь другую работу и не паришься.

  • Уходя уходи: почему не стоит принимать контроффер
    0

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

  • Уходя уходи: почему не стоит принимать контроффер
    +6

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

  • Уходя уходи: почему не стоит принимать контроффер
    +1

    Давненько вы нас покинули :-) Понятие КЗоТ исчезло в 2002-м году, сменившись на ТК. Сейчас многие компании платят в белую, оформляют официально, уважают отпуска, больничные и прочее. Ну и подпортить компании карму, накапав в налоговую, стало гораздо проще.

  • Уходя уходи: почему не стоит принимать контроффер
    +5
    Все в среднем работу меняют раз в 1-3 года, очень мало кто вообще больше 4х лет сидит

    Откуда статистика?

  • Уходя уходи: почему не стоит принимать контроффер
    0
    еще с годик проработал в абсолютно таких же условиях.

    Что подтверждает тезис о том, что большинство сотрудников уходит через 6-12 месяцев после выставления контроффера.

  • Уходя уходи: почему не стоит принимать контроффер
    0

    Почему "в любом случае"? Я считаю, что не в любом.

  • Максимальное количество значений в enum Часть I
    0

    Нет-нет, один пустой свитч :-) А чего ты гадаешь вообще? Кодогенератор тривиально написать и установить граница экспериментально.

  • В «osu!» играй, про ошибки не забывай
    +1
    А можно просто уметь это делать и находить сотни подобных интересных срабатываний, как это делает PVS-Studio

    Я согласен, что это интересное срабатывание для вас, и вы наверняка гордитесь таким межпроцедурным анализом, это всё понятно. Вопрос в том, есть ли от него польза пользователям. Где-то в другом месте может быть и есть, но здесь это кажется лишним шумом.

  • В «osu!» играй, про ошибки не забывай
    0
    public void UpdateProgress(double completionProgress)
    {
      ....
      Rotation = -90 + (float)(-Math.Atan2(diff.X, diff.Y) * 180 / Math.PI);
      ....
    }

    Довольно очевидно, что серьёзной ошибки здесь нет. Во-первых, перепутанные x и y поменяют направление вращения. Если бы что-то вращалось не в ту сторону, то либо это бы сразу заметили, либо в принципе направление вращения здесь не важно (в играх такое вполне бывает). Я могу предположить, что автор действительно не разобрался, какие аргументы принимает Atan2, но потом добавил приседания с минусом и вычитанием 90 градусов, чтобы подогнать под требуемый результат. То есть формулу можно упростить, но понятно, что ошибки тут нет. Вообще когда речь идёт о вращениях на плоскости, x и y могут запросто переставиться. Такое эмпирическое предупреждение всегда шито белыми нитками.

  • В «osu!» играй, про ошибки не забывай
    +1
      if (!base.OnPressed(action))
        return false;

    Ну такой межпроцедурный анализ — это, конечно, круто, но кажется, что вместо всего этого надо просто выдать один варнинг внутри updateResult:


    return Judged; // value is always false

    Ну можно на весь метод updateResult ругнуться, что он всегда возвращает false. Но протаскивать эту информацию на каждую точку вызова кажется довольно нелепо. Программирование — это про абстракцию и инкапсуляцию. Поведение updateResult инкапсулировано, по контракту (возвращаемый тип bool — это контракт) он может возвращать разное значение. Неочевидно, что стоит выдавать какие-то варнинги в точках вызова, это только шум. Точки вызова должны быть готовы к любой допустимой контрактом реализации метода.

  • Какие английские слова IT-лексикона мы неправильно произносим чаще всего
    +1

    Тут тоже второстепенное ударение, как в syntax.

  • Какие английские слова IT-лексикона мы неправильно произносим чаще всего
    0

    Интересны слова с второстепенным ударением. Например, syntax. Тут не просто сИнтэкс, как многие русские произносят, а /ˈsinˌtaks/, ударение на втором слоге отчётливо слышно.

  • Максимальное количество значений в enum Часть I
    +1

    После установления точной границы интересное предложение исследования — сделать хотя бы один свитч по этому енаму. Хоть бы и пустой. Сработает? Или придётся лимит ещё снижать?

  • Что делать, если забыт код от замка чемодана?
    0

    Почему от таможни? От случайных прохожих. Таможня-то понятно что откроет, если надо.

  • Что делать, если забыт код от замка чемодана?
    0

    Я отжимал отвёрткой такой замок как на последней картинке в статье. Комбинацию так и не узнал (пробовали перебирать, безуспешно). Теперь просто навесным закрываем. После этой статьи можно попробовать, конечно. Но отвёрткой отжать реально несложно.

  • Математики достигли прорыва в изучении «опасной» задачи
    0

    Хм. У меня переполнение наступает позже, на числе 23,035,537,407 (за две минуты доходит до этого числа на джаве). Я оптимизировал следующим образом. Во-первых, уже отметили, что можно рассматривать только нечётные числа. Соответственно будем перебирать не x из исходной постановки задачи, а y = (x-1)/2. То есть x = 2y+1, и тогда следующее число за ним — 3x+1 = 6y+4. Очевидно, оно чётное, сразу делим пополам (3y+2). Далее его делим на два пока делится (то есть обрезаем правые нулевые биты), а потом вычитаем единицу и ещё раз делим на два, чтобы получить новый y (то есть обрезаем ещё один единичный бит). По сути надо сдвинуть результат вправо на numberOfTrailingZeros+1. NumberOfTrailingZeros — это инструкция TZCNT, быстро работает. С помощью этих оптимизаций мы также отыгрываем один битик от числа, то есть можем работать с 65-битным промежуточным результатом.


    Код на Java
    public class Collatz {
      public static void main(String[] args) {
        long limit = Long.divideUnsigned(-1L, 3) - 2;
        for (long num = 1; ; num++) {
          for (long next = update(num); next >= num; next = update(next)) {
            if (next == num || next > limit) {
              System.out.println((next == num ? "Found: " : "Overflow at: ") + (num * 2 + 1));
              return;
            }
          }
        }
      }
    
      private static long update(long value) {
        value = value * 3 + 2;
        return value >>> (Long.numberOfTrailingZeros(value) + 1);
      }
    }

    В Java нет типа unsigned long, но это никому не мешает. Сложение и умножение для signed и unsigned работает одинаково, есть операция беззнакового битового сдвига >>>, а для деления есть специальный метод divideUnsigned.

  • Математики достигли прорыва в изучении «опасной» задачи
    +1

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

  • Топ 10 ошибок в проектах Java за 2019 год
    0

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

  • Топ 10 ошибок в проектах Java за 2019 год
    0

    del

  • Топ 10 ошибок в проектах Java за 2019 год
    +2

    В целом:


    • Идея репортит 10, 9 (первый кейс), 8, 7, 6, 4.
    • 5 репортить и не стоит, смотрите выше
    • 9.2 репортить было бы хорошо, но это тоже unsound warning (а вдруг снаружи метода всегда проверяется, что x != index_64.length?). У меня была черновая реализация, но возникают помимо хороших варнингов реально очень мутные false-positive, где голову сломаешь перед тем как докажешь, что анализатор неправ. Я поэтому убрал этот код. Возможно, стоит вернуться.
    • 3 должен репортиться инспекцией Integer multiplication or shift implicitly cast to long, но почему-то не срабатывает. Проверю, починю, спасибо!
    • 2 — это интересная штука, у нас прямого аналога нет. Кое-какие циклы инициализации репортятся косвенно, но прямо такой нету.
    • 1 — варнинг крутой, но как я понял инспекция у вас эвристическая. Возникает вопрос, сколько мусора она репортит. Вообще преаллоцированные массивы в toArray() в наши дни — антипаттерн. У нас на это есть инспекция, которая подсвечивает верхний по дефолту, но как раз молчит в нижнем, потому что вдруг пользователь реально хотел массив другой длины (чтобы были null'ы в хвосте).