Комментарии 11
Как в целом качество кода в сравнении с WPF?
Вы можете попробовать сравнить качество кода этих проектов с помощью нашего анализатора
Я, конечно, всё понимаю, но зачем затирать строкой "..." комментарий прямо перед кодом на который ваш анализатор дал ложное срабатывание.
Но ложное срабатывание в статью включить нельзя, да.
Если кратко, то что там происходит: во время выполнения render pass (который в себя включает так же layout) контролам разрешено менять свойства как свои так и других контролов. Это может привести к тому что layout будет запрошен повторно, что модифицирует поле _invokeOnRenderCallbacks, что мы и проверяем после обхода колбеков с предыдущего прохода цикла.
WPF в аналогичном участке содержит так же вызов событий Loaded, но уже после того как уляжется обычный лейаут. Мы это у себя в дальнейшем реализуем в 12.0 (для 11.х это было бы ломающим изменением порядка вызова событий).
Hidden text
Issue 2 тоже ложное срабатывание. Но чтобы с этим разобраться, надо сначала понять модель лэйаута и какие бывают контролы. В частности, Canvas предоставляет неограниченное внутреннее пространство для размещения контролов независимо от предоставленного ему родительским элементом места. Поэтому availableSize заменяется на бесконечно доступное. А возвращаемое значение говорит, что заберёт он себе доступный минимум. И помним, что измерения размеров дочерними элементами управления ценно побочным эффектом: теперь все дети знают свои размеры и это будет использовано дальше, в layout phase.
Да, в Issue 2 автор перезаписывает результат переменной с конкретной целью. Но параметр передается в метод и там не используется, точнее сразу перезаписывается. Как будто с дизайном что-то не так.
override в методе видели?
Во многих ваших статьях проскальзывает мысль, что проблема вот тут, независимо от контекста. По факту у Вас сейчас происходит то, что написано в соседней статье от Вашего же коллеги: https://habr.com/ru/companies/pvs-studio/articles/922616/
Да, override на этом методе действительно есть, и все другие реализации уже не допускают того же, на что указало срабатывание в статье. Но зачем в исходной реализации параметр перетирается? Выглядит как не самое хорошее решение, потому в статью и попало. Кстати, помимо этого, у данного метода даже есть две реализации, которые похожи как две капли воды :)
В общем, скорее всего нам стоило вынести это срабатывание анализатора в раздел про чистоту кода, поскольку это определённо не прям-таки баг. Но мне кажется, что как указатель на странные решения в ООП дизайне, это срабатывание вполне имеет право на жизнь. Это буквально "Человек, задумайся!" от анализатора.
Issue 5 тоже похоже на ложное срабатывание. Для этого надо смотреть более широкий контекст. В первую очередь не приходит ли данное свойство из какого-интерфейса, в других реализациях которого могут быть другие варианты, а код оставлен для унификации между ветвями для сокращения неожиданностей.
Нет, класс, в котором реализован этот метод не наследует интерфейсов. Этот метод используется в коде три раза, в разных условиях, и постоянно будет возвращать false.
Путешествие по Avalonia