Ваша позиция понятна, но психология человека не такая простая вещь и человек не всегда рационален. Я, например, по себе знаю, что просмотр видео с какой-нибудь адской расчленёнкой проникает в мой мозг глубже, чем я хотел бы, и меняет умственную деятельность в направлении, которое мне не нравится. При этом этот процесс слабо поддаётся контролю. Я не могу просто рационально воспринять эту информацию в виде «ок, принято, так в жизни бывает, надо быть к такому готовым, поступать так как эти люди — плохо». Появляются всякие эмоции, ненависть, отвращение и т. д., которые потом препятствуют нормальной жизнедеятельности и я не могу их быстро подавить. Вероятно это оставляет долговременный след в голове, который мне там не нужен. Вообще стоит особо щепетильно относиться к тому, что складываешь в голову, оттуда не так-то просто удалять файлы.
Во всяком случае я пришёл к выводу, что для моего мозга просмотр подобных видеоматериалов приносит больше вреда чем пользы, и лучше их избегать. Лучше действительно почитать чью-нибудь заметку с текстовым описанием. Есть шанс, что в заметке что-то переврано (хотя если это реддит, там будет миллион комментариев, где автора ткнут носом). Есть шанс, что у меня сложится искажённое восприятие действительности. Взамен я не получаю трудногасимого эмоционального фона в голове. Я считаю этот обмен выгодным. Моё неправильное мнение о такой проблеме вряд ли как-то повлияет на окружающий мир. А если я начну без причины грубить окружающим, только потому что до этого посмотрел какую-то дрянь, вреда миру будет больше.
Я полагаю, что не на меня одного подобные вещи воздействуют негативно, хотя готов принять, что есть люди, которые не подвержены такому влиянию. При этом жизненный опыт подсказывает, что очень мало людей критически анализируют то что происходит в их голове. Я могу признать, что для меня гадкие видеозаписи вредны. Другой человек не признает, а с радостью посмотрит, и трудно предсказать, что у него после этого перещёлкнет в мозгу. Поэтому я бы не стал всем подряд показывать всё подряд. Вы же не запускаете любые исполняемые файлы из интернета на всех подряд компьютерах.
Ведь тогда у неё будет точно ограниченный список файлов для проверки и индексация должна проходить быстрее для случаев, когда в пакете 20 классов, а включено всего 4.
На индексацию повлиять не должно: как я писал в статье, во время индексации всё равно символы не разрешаются. В процессе нормальной работы, конечно, явный импорт ускоряет разрешение символов.
Не может быть, чтобы константа CursorShowing равнялась 0, ведь буквально парой строк выше она инициализирована значением 1.
Вот тут, кстати, видна разница между отдельным инструментом статического анализа и статическим анализатором, встроенным в IDE. Ведь в IDE вы бы сразу в точке предупреждения нажали "перейти к определению символа" и обнаружили бы причину в ту же минуту. Не пришлось бы долго разбираться и даже создавать тикет в баг-трекере.
Если же действительно в анализаторе ошибка, будет легче понять, где она. Так как анализатор переиспользует ту же процедуру разрешения символа, что и функция перехода к объявлению, вы сразу поймёте, ошибка в анализе или в разрешении символов.
Приходится, работа такая. Интересно, что с выхода восьмой Джавы по материалам этой главы спецификации исправили десятки багов и в компиляторе javac, и в компиляторе ecj, и в нашей IDE (хотя мы не полноценный компилятор, но вывод типов у нас должен быть полностью реализован). И ещё остались тёмные места, с которыми никто пока не разобрался. А иногда баги были в тексте спецификации, и сотрудникам Оракла приходилось править её. Это действительно трудно прочитать, правильно понять и правильно реализовать.
Вот, к примеру, мы пишем Java IDE. Вчера благодаря статическому анализу я обнаружил ошибку в процедуре рефакторинга Inline method. Код, на котором она проявляется, следующий (пытаемся инлайнить метод getTwice):
class Test {
enum Foo {
BAR(getTwice(() -> {
return getNum();
}));
Foo(int val) {}
}
static int getNum() {
return 4;
}
static int getTwice(IntSupplier fn) {
int x = fn.getAsInt();
int y = fn.getAsInt();
return x + y;
}
}
Чтобы баг проявился, необходимо выполнение следующих условий:
Метод, который мы инлайним, должен возвращать значение
Метод, который мы инлайним, должен быть сложнее, чем просто один return, должно быть минимум два оператора в его теле
Метод, который мы инлайним, должен вызываться в конструкторе enum-константы
Среди аргументов этого метода должно быть лямбда-выражение
В лямбда-выражении должен быть полноценный return (простая expression-lambda не подойдёт)
return в этой лямбде должен возвращать результат другого метода (не константу, не арифметическую операцию, не переменную, а именно результат метода)
Только при выполнении всех условий рефакторинг не срабатывает, а IDE выдаёт исключение. Рефакторингу больше 15 лет, им пользовались миллионы раз в самых разнообразных проектах, никто никогда не сообщил об этой проблеме. Возможно, никто просто ещё не написал настолько извратный Java-код. А статический анализатор играючи указал на ошибку в нашем коде. Исправление тривиальное, а вот чтобы сконструировать тест-кейс, где ошибка проявляется, я потратил около получаса. Стоило ли исправлять или дожидаться недовольного пользователя? Как считаете?
V728 An excessive check can be simplified. The '(A && B) || (!A && !B)' expression is equivalent to the 'bool(A) == bool(B)' expression
Вы же всё время хвастаетесь, что концентрируетесь на реальных багах, а не на стиле кодирования? А это чисто стилистическое. Некоторым людям трудно представить булево значение в контексте любой операции кроме &&, ||,!.. Ну просто мозг не поворачивается в эту сторону. Поэтому они пишут длинно.
Да, калькулятор сильно людям понравился. Вроде обычная статья от PVS-Studio, каких много, а столько плюсиков и комментариев!
An odd precise comparison: ratio == threshold
Мой опыт показывает, что эта инспекция слишком шумная и сделать её адекватной, то есть чтобы она указывала на реальные баги и не указывала на всякий мусор, довольно сложно. Но как минимум сравнения с нулём крайне редко бывают полезными предупреждениями. Я не помню ни единого случая из своей программистской практики, когда написанное программистом doubleValue == 0.0 приводило к багам, а abs(doubleValue) < someEpsilon исправляло эти баги. Рекомендую при нуле не предупреждать. Аналогично при единице. Среди тысяч найденных вами ошибок за годы работы есть хоть одна, где явное сравнение с единицей было проблемой?
Теперь вернёмся к threshold. Эта переменная имеет значение 0 во всех формах и только в форме UnitConverter имеет значение 1. Соответственно данное сравнение тоже скорее всего безопасно.
Даже не так. В случае если ActiveIfEqual == false, isActive = ratio > threshold. В случае если ActiveIfEqual == true, isActive = ratio >= threshold. Скажите, вы ругаетесь на операцию >=? Ведь здесь фактически она и есть.
В старой утечке исходников Windows 2000 тоже был ещё старый калькулятор. Любопытно, что эти исходники лежат на гитхабе. Интересно, в курсе ли Микрософт?..
Суть гравитационного маневра Вояджеров на пролёте мимо планеты, когда планета делится частью своего импульса, для меня вполне понятна, и существенная экономия топлива не вызывает сомнений. При таком манёвре вообще можно обойтись без затрат топлива. Тут же ситуация выглядит по-другому: космический аппарат уже движется по эллиптической орбите вокруг данной планеты, и просто так она поделиться импульсом не может. В каких точках орбиты включение двигателя помогает? Важно ли движение Земли вокруг Солнца или наличие Луны для такого манёвра?
Интересно, а почему постепенно увеличивать апогей выгоднее, чем сразу разогнать до второй космической? И насколько выгоднее в терминах расхода топлива или стоимости миссии?
Думал, это перевод старой статьи Лукаса. Оказалось, что нет.
Во всяком случае я пришёл к выводу, что для моего мозга просмотр подобных видеоматериалов приносит больше вреда чем пользы, и лучше их избегать. Лучше действительно почитать чью-нибудь заметку с текстовым описанием. Есть шанс, что в заметке что-то переврано (хотя если это реддит, там будет миллион комментариев, где автора ткнут носом). Есть шанс, что у меня сложится искажённое восприятие действительности. Взамен я не получаю трудногасимого эмоционального фона в голове. Я считаю этот обмен выгодным. Моё неправильное мнение о такой проблеме вряд ли как-то повлияет на окружающий мир. А если я начну без причины грубить окружающим, только потому что до этого посмотрел какую-то дрянь, вреда миру будет больше.
Я полагаю, что не на меня одного подобные вещи воздействуют негативно, хотя готов принять, что есть люди, которые не подвержены такому влиянию. При этом жизненный опыт подсказывает, что очень мало людей критически анализируют то что происходит в их голове. Я могу признать, что для меня гадкие видеозаписи вредны. Другой человек не признает, а с радостью посмотрит, и трудно предсказать, что у него после этого перещёлкнет в мозгу. Поэтому я бы не стал всем подряд показывать всё подряд. Вы же не запускаете любые исполняемые файлы из интернета на всех подряд компьютерах.
На индексацию повлиять не должно: как я писал в статье, во время индексации всё равно символы не разрешаются. В процессе нормальной работы, конечно, явный импорт ускоряет разрешение символов.
Почему же пришлось так долго разбираться с этой проблемой?
Вот тут, кстати, видна разница между отдельным инструментом статического анализа и статическим анализатором, встроенным в IDE. Ведь в IDE вы бы сразу в точке предупреждения нажали "перейти к определению символа" и обнаружили бы причину в ту же минуту. Не пришлось бы долго разбираться и даже создавать тикет в баг-трекере.
Если же действительно в анализаторе ошибка, будет легче понять, где она. Так как анализатор переиспользует ту же процедуру разрешения символа, что и функция перехода к объявлению, вы сразу поймёте, ошибка в анализе или в разрешении символов.
Зачем? Оператор ?: есть, начиная с первой джавы.
Вот, к примеру, мы пишем Java IDE. Вчера благодаря статическому анализу я обнаружил ошибку в процедуре рефакторинга Inline method. Код, на котором она проявляется, следующий (пытаемся инлайнить метод getTwice):
Чтобы баг проявился, необходимо выполнение следующих условий:
Только при выполнении всех условий рефакторинг не срабатывает, а IDE выдаёт исключение. Рефакторингу больше 15 лет, им пользовались миллионы раз в самых разнообразных проектах, никто никогда не сообщил об этой проблеме. Возможно, никто просто ещё не написал настолько извратный Java-код. А статический анализатор играючи указал на ошибку в нашем коде. Исправление тривиальное, а вот чтобы сконструировать тест-кейс, где ошибка проявляется, я потратил около получаса. Стоило ли исправлять или дожидаться недовольного пользователя? Как считаете?
Вот вам сорцы того самого калькулятора!
Вы же всё время хвастаетесь, что концентрируетесь на реальных багах, а не на стиле кодирования? А это чисто стилистическое. Некоторым людям трудно представить булево значение в контексте любой операции кроме &&, ||,!.. Ну просто мозг не поворачивается в эту сторону. Поэтому они пишут длинно.
Да, калькулятор сильно людям понравился. Вроде обычная статья от PVS-Studio, каких много, а столько плюсиков и комментариев!
Мой опыт показывает, что эта инспекция слишком шумная и сделать её адекватной, то есть чтобы она указывала на реальные баги и не указывала на всякий мусор, довольно сложно. Но как минимум сравнения с нулём крайне редко бывают полезными предупреждениями. Я не помню ни единого случая из своей программистской практики, когда написанное программистом
doubleValue == 0.0приводило к багам, аabs(doubleValue) < someEpsilonисправляло эти баги. Рекомендую при нуле не предупреждать. Аналогично при единице. Среди тысяч найденных вами ошибок за годы работы есть хоть одна, где явное сравнение с единицей было проблемой?Теперь вернёмся к threshold. Эта переменная имеет значение 0 во всех формах и только в форме UnitConverter имеет значение 1. Соответственно данное сравнение тоже скорее всего безопасно.
Даже не так. В случае если ActiveIfEqual == false,
isActive = ratio > threshold. В случае если ActiveIfEqual == true,isActive = ratio >= threshold. Скажите, вы ругаетесь на операцию>=? Ведь здесь фактически она и есть.Ну так это почти двадцать лет назад было. С тех пор технологии калькулирования-то сильно шагнули вперёд!
В старой утечке исходников Windows 2000 тоже был ещё старый калькулятор. Любопытно, что эти исходники лежат на гитхабе. Интересно, в курсе ли Микрософт?..
Во, спасибо.
Суть гравитационного маневра Вояджеров на пролёте мимо планеты, когда планета делится частью своего импульса, для меня вполне понятна, и существенная экономия топлива не вызывает сомнений. При таком манёвре вообще можно обойтись без затрат топлива. Тут же ситуация выглядит по-другому: космический аппарат уже движется по эллиптической орбите вокруг данной планеты, и просто так она поделиться импульсом не может. В каких точках орбиты включение двигателя помогает? Важно ли движение Земли вокруг Солнца или наличие Луны для такого манёвра?
Вероятно тут речь об эффекте Оберта. Или нет?
Интересно, а почему постепенно увеличивать апогей выгоднее, чем сразу разогнать до второй космической? И насколько выгоднее в терминах расхода топлива или стоимости миссии?
Обсуждают неспеша, но как-то нет уверенности, что даже в 13 завезут.