Должны ли методы жизненного цикла Unity аннотироваться атрибутом UsedImplicitly?


9

Помогает ли аннотирование методов жизненного цикла Unity с помощью UsedImplicitlyатрибута улучшить читабельность вашего кода?

Например:

public class Example : MonoBehaviour
{
    [UsedImplicitly]
    private void Awake()
    {
        DoSomething();
    }

    private void DoSomething()
    {
        // ...
    }
}

Этот пост в блоге "Структурирование вашего единства MonoBehaviours" предлагает этот подход в качестве полезного соглашения.

  1. Аннотируйте все методы жизненного цикла Unity (Start, Awake, Update, OnDestroy и т. Д.), Методы событий и другие функции, которые неявно (или автоматически) вызываются в вашем коде с атрибутом [UsedImplicitly]. Этот атрибут, хотя и включен в UnityEngine.dll, используется ReSharper для отключения предложений по очистке кода для методов, которые, по-видимому, не ссылаются. Это также помогает упростить чтение кода для людей, которые являются новичками в Unity и вашей кодовой базе, особенно для событий, на которые ссылается инспектор.

(Примечание: я не думаю, что ReSharper предлагает рекомендации по очистке кода для, казалось бы, не связанных методов жизненного цикла Unity, так что это может быть устаревшим советом.)

Я согласен с приведенным выше постом, что он может быть полезен для новичков в Unity. Я также думаю, что было бы полезно пометить те функции жизненного цикла Unity , которые используются не так часто, какAwake , Startи Update. Но мне интересно, действительно ли это хорошее соглашение для «чистого кода» или это просто шум, который снижает читабельность.


1
Я опубликовал 2 игры в Unity и не знал, что это существует. Если бы я это сделал, я бы использовал это для ясности и не стал бы считать это шумом.
Макаден

1
Эй, я оригинальный автор поста. Да, я думаю, что это может быть излишним для методов жизненного цикла, особенно с учетом улучшенной поддержки Resharper. Однако я думаю, что полезно аннотировать обратные вызовы событий (например, для анимации и системы событий пользовательского интерфейса Unity), на которые ссылаются только через инспектор. Хотя дело за людьми, управляющими базой кода - когда я писал это, я работал в консалтинговой компании, где никто не имел опыта разработки игр, поэтому я хотел установить стандарт между нами. В ретроспективе это немного драконовски, так как я не ожидал, что пост привлечет внимание.
Мана

Ответы:


10

Это зависит от целевой аудитории.

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

Любой, кто когда-либо читал базовый учебник по Unity, прекрасно это знает Startи Updateнеявно используется движком Unity, поэтому он не даст им никакой новой информации. Это может на самом деле запутать их, если вы забудете об этом однажды. Что ты хочешь сказать этим? Может быть, это на самом деле не MonoBehaviour? Или есть какая-то неясная причина, почему вы должны назвать это явно, о которой я не знаю?

Это может, однако, помочь, если вы работаете с неопытными разработчиками, которые могут быть не знакомы с более эзотерическими событиями Unity, такими как Reset(опасно, потому что явный вызов этого может сделать не так, как вы думаете). [UsedImplicitly]Атрибут мог бы тогда сказать им , что они не должны искать класс , который вызывает этот метод , потому что двигатель делает. Но опять же, это имеет значение, только если у вас есть дисциплина, чтобы делать это последовательно. И если у вас есть такое количество самодисциплины, вы могли бы также согласиться на добавление комментария.


1
Я бы добавил, что «на 99% это не дает никакой пользы». Даже новички через несколько часов начнут распознавать методы жизненного цикла (они по-разному окрашены в VS!). И еще более резким является то, что дорогая лицензия может быть перенастроена, и, как сказал OP, она, вероятно, уже исправлена. Я думаю , что можно тратить свое время более эффективно , чем украшать каждый второй метод с атрибутами спорного значения.
Wondra

@wondra Спасибо, что указали на то, что они окрашены по-разному в Visual Studio. Я попытаюсь выяснить, почему он не делает этого для меня с Visual Studio 2017, хотя для Tools -> Options -> Tools for Unity -> General -> Unity Messages syntax highlightingнего установлено значение true.
сынок,

1
Я не изучал, почему Visual Studio не окрашивал мои методы Unity, но другой ответ указал, что в ReSharper есть плагин для Unity, который также автоматически распознает функции событий Unity. Существует также это связано установка: ReSharper -> Options -> Code Inspection -> Settings -> Enable code analysis -> Color identifiers.
сынок

6

Я утверждаю, что нет, вы не должны его использовать.

Атрибут UsedImplicitly взят из пространства имен Jetbrains.Annotations, поэтому он может применяться только в том случае, если все, кто использует код, будут использовать ReSharper.

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

Я также хотел бы добавить пример, когда их использование может пойти не так. Предположим, у вас есть класс, унаследованный от MonoBehaviour, но после рефакторинга он больше не наследуется. Если вы пометили закрытые методы с помощью [UsedImplicitly], вы не получите правильных предупреждений. Если вы используете плагин Unity для resharper, он заметит, что вы больше не наследуете от MonoBehaviour, и выдаст предупреждения, так как методы больше не вызываются.


1
Я не знал, что плагин ReSharper существует, спасибо за указание на это!
сынок

1
Обратите внимание, что Unity начала включать атрибуты ReSharper в UnityEngine.dll начиная с Unity 5 - см. Этот пост на форуме .
сынок

5

Я бы сделал аргумент, что это не может повредить.

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

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

Кроме того, если кто-то использует инструменты статического анализа, которые неправильно предупреждают о методах, тогда вы захотите как-то скрыть эти предупреждения, потому что «игнорируемый» предупреждающий шум затрудняет просмотр реальных предупреждений в любом таком выводе. Обычно лучше игнорировать такие предупреждения хирургическим, локализованным способом (в данном случае путем украшения нарушающих методов атрибутами), чем с помощью более широких мер, таких как отключение этого конкретного предупреждения в рамках всего проекта.


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

3
Да, это справедливо. Если у вас есть статический анализ, который опровергает это, а другой серьезно относится к этим предупреждениям, это поможет вам обеспечить единообразное применение атрибута. Но если нет? Это в значительной степени до человеческой ошибки тогда.

2

Проблема этого подхода в том, что он невероятно подвержен ошибкам.

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

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

  1. Проверять и отклонять несоответствующий код при регистрации или автоматической сборке.
  2. Автоматическое редактирование кода для исправления тегов при регистрации или автоматическая сборка.

Стоит ли это иметь? Да. Это стоит 2 часа вашего времени? Ваш звонок.


1
Я принял другой ответ, но вы замечаете, что устраняете человеческую ошибку для всех, кто задумывается об использовании UsedImplicitlyатрибута для этой цели.
сынок
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.