Хм, довольно странно, что возникли какие-то проблемы с CompilerCommandsAnalyzer. Возможно, я не совсем понял ваш сценарий. Буду благодарен, если напишите нам тут, мы бы попробовали разобраться в данном вопросе.
Вот тут есть форма обратной связи. Публичного issue-трекера нет, однако вам, очевидно, ответят на все вопросы и вполне возможно починят, после чего отпишут вам. Довольно часто все найденные пользователями проблемы чинятся, хотя очевидно, что запросы клиентов будут в приоритете.
Я записал себе ваш кейс, однако если вам интересно хотя бы в каком-то виде "отслеживать" его починку, то вероятно, будет лучше написать в форму. Хотя с другой стороны, я могу вам о починке написать тут, если вы заинтересованы :).
В любом случае, спасибо, что сообщили о ложных срабатываниях с new() :). Надеюсь, скоро доберёмся до них.
Мне кажется, мы говорим о разных вещах, LordDarklight. Определённо, то о чём вы рассказываете, крайне интересно. И всё это было бы круто, и к этому надо стремиться. Я бы даже хотел почитать что-нибудь на эту тему - если не сложно, скиньте каких-нибудь ссылок, пожалуйста. К сожалению, к теме статьи рассуждения об идеальном будущем не очень относятся и отдают максимализмом.
Статья говорит о том, что чуваки не подвинули конструкцию то на строчку-другую вниз, то на строчку-другую вверх. Причём увидеть эти моменты ну очень уж легко, если пишешь функцию хотя бы с одним открытым глазом. И вы на это отвечаете, что для того, чтобы такого не было, нужно будет "вылизывать код донельзя". Почему?
Почему код нужно прям обязательно "вылизать донельзя"? Неужели есть только 2 подхода - идеальная чистота и идеальная помойка? Типа
Всех странностей мы всё равно не пофиксим, не будем тратить наши драгоценные 10 секунд и на то, чтобы передвинуть разыменование под проверку. Вот будет версия 3.2 и прям отправимся все вместе убираться в этом море кода, в котором уже никто и не помнит, по какой причине что и как было сделано.
Поправить такие моменты как раз и легче всего в момент, когда они только-только написаны. Именно в такие моменты их править быстро и безболезненно. Ну не хотите-не можете вы внимательно просматривать всё, что комитите - ну хоть пусть какая-нибудь автоматическая тула глянет. Если вы внедрили её правильно, то она на коммит ну не выдаст супер-много срабатываний, им там неоткуда взяться.
Кстати, может "в здравом уме" фиксить эти проблемы и не станет никто, но, как я упомянул ранее, стоило мне про эти места написать, и тут же всё пофиксили. Как ни странно, но вот нашёлся человек, который смог внести столь сложные правки, как перенос разыменований под проверку). И я очень надеюсь, что он знал, что делал, и что действительно в тех фрагментах правка должна быть именно такой.
Я полностью согласен с вами, не нужно уходить в крайности. Но одно дело "код не нравится", а другое - "код выглядит стрёмно". И главное - какова цена вопроса? Потратить секунду на то, чтобы передвинуть разыменование под проверку) Во всяком случае, указанные мною места были примерно так и поправлены.
Ну во-первых, никакого "негодования" у меня нет. И в статье не написано нигде про то, что "как же это они так вот не пользуются PVS". Я совершенно не сомневаюсь, что есть и другие решения, которые могут такое ловить. Возможно, среди них и приведённый вами SonarQube.
В-вторых - приведённые мною фрагменты настолько элементарны, что написать их сразу нормально не было бы дольше или дороже. Особенно это хорошо доказывает тот факт, что соответствующий issue они поправили буквально за день.
Да и речи не идёт про "идеально чистый код". Просто то, что написано у них, выглядит ну как-то совсем небрежно. В чём проблема прогнать анализатор (хоть наш, хоть любой другой) на изменённых файлах перед коммитом и пофиксить за 5 минут все странности, чтобы они уж точно не выстрелили в будущем?
Да, указанные косяки может никогда и не выстрелят в принципе. А может выстрелят. Какой смысл рисковать, если можно просто взять и пофиксить (как собственно и сделали, когда я открыл issue)?
И кажется, что очевидно, что проще всего пофиксить код, который написан тобой только что, чем какой-нибудь застарелый кусок, который добавили условно год назад люди которых уже мб и не сыскать. Смотришь на такой вот кусок и думаешь - чё тут хотели сделать? Может тут быть null или нет? Почему так?
Рассуждения про "==" связаны с тем, что в Unity сравнение с null через "==" и правда работает не совсем так, как привычно (документация).
Про анализатор я вроде как всего раз упоминаю, больше концентрируясь не на том "как невероятно круто что он нашёл", а просто на том, что в столь серьёзном проекте тут и там такой вот, как вы выразились, код "за гранью любой допустимости".
Потому что проще поверить что x.y стал overloadable чем в то, что с null упадёт.
Это уже вопрос мнения. Откровенно говоря - вы бы нормально отнеслись бы к тому, что такой код есть на вашем проекте? Ну вроде как "работает и ладно".
Кстати да - насколько я видел, оно у них выключено. С другой стороны, эта штука реально много ложек выдаёт и это мб раздражает. Но сторонние платные инструменты всё же поумнее в этом могут быть (просто потому, что работают не "на лету" и учитывают кучу всяких дополнительных особенностей и т.п.).
Просто это не особо логично - писать сразу ВЕСЬ код огромного проекта "кое-как" безо всяких там инструментов и прочего, а потом в конце за неделю до релиза обнаружить миллион срабатываний и спешно разгребать, какие из них там ложные, какие нет и т.п.
Не совсем понял вас. Я не писал о том, что что-либо падает. Я писал о том, что разработчики будто бы сами не понимали, какие данные они хотят обрабатывать. Вы не согласны с тем, что представленный код выглядит странно? (при этом даже не содержит ни одного комментария типа "тут всё окей, так надо").
По поводу ".Parent". Вообще я не думаю, что это окей, когда обращение к свойству экземпляра это "не то, чем кажется". Кажется, это какая-то нездоровая тема. С другой стороны, для повышения собственного уровня образованности мне было бы правда интересно узнать о том, как можно обратиться к свойству у null так, чтобы не было исключения. Если у вас есть мысли на этот счёт, то прошу поделиться :).
Не могли бы вы, пожалуйста, привести пример ошибки, связанной с учётом особенностей .NET Framework? К примеру, в анализаторе есть правило V5614, которое учитывает версию .NET Framework при исследовании кода на уязвимость к XXE. Вы имеете ввиду подобные случаи или что-то другое?
Вы имеете ввиду топ категорий ошибок, найденных статическим анализатором в open-source проектах? Возможно, это и правда было бы интересно, спасибо за мысль!
Хм, довольно странно, что возникли какие-то проблемы с CompilerCommandsAnalyzer. Возможно, я не совсем понял ваш сценарий. Буду благодарен, если напишите нам тут, мы бы попробовали разобраться в данном вопросе.
О да, с этими штуками нужно держать ухо востро).
Но, кстати, в плане enum-ов, наверное, главное, чтобы битовое представление было ожидаемым.
Кто знает) Я тоже не до конца понял суть этого нововведения, но мб кто сможет пояснить за эту тему...
Вот тут есть форма обратной связи. Публичного issue-трекера нет, однако вам, очевидно, ответят на все вопросы и вполне возможно починят, после чего отпишут вам. Довольно часто все найденные пользователями проблемы чинятся, хотя очевидно, что запросы клиентов будут в приоритете.
Я записал себе ваш кейс, однако если вам интересно хотя бы в каком-то виде "отслеживать" его починку, то вероятно, будет лучше написать в форму. Хотя с другой стороны, я могу вам о починке написать тут, если вы заинтересованы :).
В любом случае, спасибо, что сообщили о ложных срабатываниях с new() :). Надеюсь, скоро доберёмся до них.
Ну, была бы не правда, то они бы не починили это тут)
Мне кажется, мы говорим о разных вещах, LordDarklight. Определённо, то о чём вы рассказываете, крайне интересно. И всё это было бы круто, и к этому надо стремиться. Я бы даже хотел почитать что-нибудь на эту тему - если не сложно, скиньте каких-нибудь ссылок, пожалуйста. К сожалению, к теме статьи рассуждения об идеальном будущем не очень относятся и отдают максимализмом.
Статья говорит о том, что чуваки не подвинули конструкцию то на строчку-другую вниз, то на строчку-другую вверх. Причём увидеть эти моменты ну очень уж легко, если пишешь функцию хотя бы с одним открытым глазом. И вы на это отвечаете, что для того, чтобы такого не было, нужно будет "вылизывать код донельзя". Почему?
Почему код нужно прям обязательно "вылизать донельзя"? Неужели есть только 2 подхода - идеальная чистота и идеальная помойка? Типа
Всех странностей мы всё равно не пофиксим, не будем тратить наши драгоценные 10 секунд и на то, чтобы передвинуть разыменование под проверку. Вот будет версия 3.2 и прям отправимся все вместе убираться в этом море кода, в котором уже никто и не помнит, по какой причине что и как было сделано.
Поправить такие моменты как раз и легче всего в момент, когда они только-только написаны. Именно в такие моменты их править быстро и безболезненно. Ну не хотите-не можете вы внимательно просматривать всё, что комитите - ну хоть пусть какая-нибудь автоматическая тула глянет. Если вы внедрили её правильно, то она на коммит ну не выдаст супер-много срабатываний, им там неоткуда взяться.
Кстати, может "в здравом уме" фиксить эти проблемы и не станет никто, но, как я упомянул ранее, стоило мне про эти места написать, и тут же всё пофиксили. Как ни странно, но вот нашёлся человек, который смог внести столь сложные правки, как перенос разыменований под проверку). И я очень надеюсь, что он знал, что делал, и что действительно в тех фрагментах правка должна быть именно такой.
Я полностью согласен с вами, не нужно уходить в крайности. Но одно дело "код не нравится", а другое - "код выглядит стрёмно". И главное - какова цена вопроса? Потратить секунду на то, чтобы передвинуть разыменование под проверку) Во всяком случае, указанные мною места были примерно так и поправлены.
Важен баланс, короче говоря :).
Ну во-первых, никакого "негодования" у меня нет. И в статье не написано нигде про то, что "как же это они так вот не пользуются PVS". Я совершенно не сомневаюсь, что есть и другие решения, которые могут такое ловить. Возможно, среди них и приведённый вами SonarQube.
В-вторых - приведённые мною фрагменты настолько элементарны, что написать их сразу нормально не было бы дольше или дороже. Особенно это хорошо доказывает тот факт, что соответствующий issue они поправили буквально за день.
Да и речи не идёт про "идеально чистый код". Просто то, что написано у них, выглядит ну как-то совсем небрежно. В чём проблема прогнать анализатор (хоть наш, хоть любой другой) на изменённых файлах перед коммитом и пофиксить за 5 минут все странности, чтобы они уж точно не выстрелили в будущем?
Да, указанные косяки может никогда и не выстрелят в принципе. А может выстрелят. Какой смысл рисковать, если можно просто взять и пофиксить (как собственно и сделали, когда я открыл issue)?
И кажется, что очевидно, что проще всего пофиксить код, который написан тобой только что, чем какой-нибудь застарелый кусок, который добавили условно год назад люди которых уже мб и не сыскать. Смотришь на такой вот кусок и думаешь - чё тут хотели сделать? Может тут быть null или нет? Почему так?
Ну видите, не зря пишем) Ещё пара статей, и даже не будете ошибаться в названии).
В любом случае, спасибо за диалог, было интересно услышать вашу позицию.
Рассуждения про "==" связаны с тем, что в Unity сравнение с null через "==" и правда работает не совсем так, как привычно (документация).
Про анализатор я вроде как всего раз упоминаю, больше концентрируясь не на том "как невероятно круто что он нашёл", а просто на том, что в столь серьёзном проекте тут и там такой вот, как вы выразились, код "за гранью любой допустимости".
Потому что проще поверить что x.y стал overloadable чем в то, что с null упадёт.
Это уже вопрос мнения. Откровенно говоря - вы бы нормально отнеслись бы к тому, что такой код есть на вашем проекте? Ну вроде как "работает и ладно".
О каких исключениях вы бы хотели поговорить?)
Кстати да - насколько я видел, оно у них выключено. С другой стороны, эта штука реально много ложек выдаёт и это мб раздражает. Но сторонние платные инструменты всё же поумнее в этом могут быть (просто потому, что работают не "на лету" и учитывают кучу всяких дополнительных особенностей и т.п.).
Это всё печально, если честно. Идея-то прикольная(
Просто это не особо логично - писать сразу ВЕСЬ код огромного проекта "кое-как" безо всяких там инструментов и прочего, а потом в конце за неделю до релиза обнаружить миллион срабатываний и спешно разгребать, какие из них там ложные, какие нет и т.п.
Мы вроде говорили про свойство :). Да и анализатор, которым я собственно и нашёл все эти моменты, учитывает такие кейсы.
Не совсем понял вас. Я не писал о том, что что-либо падает. Я писал о том, что разработчики будто бы сами не понимали, какие данные они хотят обрабатывать. Вы не согласны с тем, что представленный код выглядит странно? (при этом даже не содержит ни одного комментария типа "тут всё окей, так надо").
По поводу ".Parent". Вообще я не думаю, что это окей, когда обращение к свойству экземпляра это "не то, чем кажется". Кажется, это какая-то нездоровая тема. С другой стороны, для повышения собственного уровня образованности мне было бы правда интересно узнать о том, как можно обратиться к свойству у null так, чтобы не было исключения. Если у вас есть мысли на этот счёт, то прошу поделиться :).
Пожалуйста) Раньше тут вроде был ещё комментарий с просьбой о пояснении. Уже разобрались во всём?
Не могли бы вы, пожалуйста, привести пример ошибки, связанной с учётом особенностей .NET Framework? К примеру, в анализаторе есть правило V5614, которое учитывает версию .NET Framework при исследовании кода на уязвимость к XXE. Вы имеете ввиду подобные случаи или что-то другое?
Вы имеете ввиду топ категорий ошибок, найденных статическим анализатором в open-source проектах? Возможно, это и правда было бы интересно, спасибо за мысль!
Я думаю, тут дело в том, что использовалась стандартная функция, которая попросту не предназначена ни для какого "MAILER") Возможно, с чем-то спутали.