Os métodos do ciclo de vida do Unity devem ser anotados com o atributo UsedImplicitly?

A anotação de métodos do ciclo de vida do Unity com o UsedImplicitlyatributo melhora a legibilidade do seu código?

Por exemplo:

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

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

Esta postagem no blog "Estruturando seus comportamentos de unidade" sugere essa abordagem como uma convenção útil.

8. Anote quaisquer métodos do ciclo de vida do Unity (Iniciar, Despertar, Atualizar, OnDestroy etc.), métodos de eventos e outras funções que são implicitamente (ou automaticamente) invocadas no seu código com o atributo [UsedImplicitly]. Esse atributo, embora incluído no UnityEngine.dll, é usado pelo ReSharper para desativar as sugestões de limpeza de código para métodos que aparentemente não são referenciados. Também ajuda a facilitar a leitura do código para as pessoas mais novas no Unity e na sua base de código, especialmente para eventos referenciados pelo inspetor.

(Observação: não acho que o ReSharper mostre sugestões de limpeza de código para métodos de ciclo de vida do Unity aparentemente sem referência, de modo que possam ser conselhos desatualizados.)

Concordo com o post acima que poderia ser útil para os mais novos no Unity. Eu também acho que poderia ser útil para rotular essas funções de ciclo de vida da unidade que não são utilizados tão frequentemente como Awake, Start, e Update. Mas estou pensando se essa é realmente uma boa convenção para "código limpo" ou se é apenas ruído que reduz a legibilidade.

Depende do alvo demográfico.

No exemplo acima, o alvo demográfico é a ferramenta ReSharper, que se beneficia desses atributos porque suprime mensagens que não são úteis para você. Mas se você não sente a necessidade de usar o ReSharper ou uma ferramenta semelhante (embora talvez deva, eles têm algumas críticas válidas de tempos em tempos), não precisa se preocupar com essa demografia.

Qualquer um que tenha feito um tutorial básico do Unity sabe muito bem disso Starte Updateé usado implicitamente pelo mecanismo do Unity, portanto, não fornecerá nenhuma informação nova. Na verdade, pode confundir os pedaços deles, se você esquecer isso uma vez. O que você quer dizer com isso? Talvez isso não seja realmente um MonoBehaviour? Ou existe alguma razão obscura pela qual você deve chamá-lo explicitamente, do qual não tenho conhecimento?

No entanto, pode ajudar se você estiver trabalhando com desenvolvedores inexperientes que talvez não estejam familiarizados com os eventos mais esotéricos do Unity, como Reset (perigoso, porque chamá-lo explicitamente pode não fazer o que você acha que faz). O [UsedImplicitly]atributo pode dizer a eles que eles não precisam procurar a classe que chama esse método porque o mecanismo o faz. Mas, novamente, isso só tem valor se você tiver a disciplina para fazer isso de forma consistente. E se você tiver essa quantidade de autodisciplina, poderá concordar em adicionar um comentário.

Eu argumento que não, você não deve usá-lo.

O atributo UsedImplicitly é do espaço de nomes Jetbrains.Annotations, portanto, o único caso em que isso pode se aplicar é se todos que usam o código estiverem usando o ReSharper.

ReSharper tem um plugin para Unity que já lida com isso para você, certificando-se não apenas de remover os avisos de que eles não são usados, mas também de marcá-los com um pequeno símbolo do Unity, para que qualquer pessoa que esteja lendo o código possa ver que é chamada pelo próprio Unity.

Eu também gostaria de adicionar um exemplo quando usá-los pode dar errado. Suponha que você tenha uma classe herdada do MonoBehaviour, mas após uma refatoração, ela não terá mais nenhuma herança. Se você marcou métodos particulares com [UsedImplicitly], não receberá os avisos corretos. Se você usar o plug-in Unity para recarregar, ele notará que você não herda mais do MonoBehaviour e emitirá avisos, já que os métodos não são mais chamados.

Eu argumentaria que não pode realmente doer.

Para alguém muito familiarizado com o funcionamento do Unity, provavelmente não adiciona nada. Essas pessoas já estarão familiarizadas com o que o tempo de execução do Unity chama em seu nome.

Mas para alguém que não é, como eu, pode ser útil. Mesmo se eu não soubesse o que significava de improviso, eu iria procurar, e isso provavelmente seria suficiente para me dar uma melhor compreensão do que estava acontecendo no código.

Além disso, se alguém usar ferramentas de análise estática que alertam incorretamente sobre os métodos, você deseja silenciar esses avisos de alguma forma, porque o ruído de aviso "ignorável" dificulta a visualização dos avisos reais em qualquer saída desse tipo. Geralmente é melhor ignorar esses avisos de maneira cirúrgica e localizada (neste caso, decorando os métodos incorretos com atributos) do que através de medidas mais amplas, como desativar esse aviso específico em todo o projeto.

O problema dessa abordagem é que ela é incrivelmente propensa a erros.

Se não for confiável, as tags deixarão de transmitir informações úteis, e sua presença ou ausência ocasionalmente conseguirá transmitir informações falsas, o que é prejudicial.

Se você decidir seguir em frente, deverá remover o erro humano, o que não é difícil de executar, mas leva duas horas de trabalho se você não tiver feito algo assim antes. Existem 2 abordagens - cada uma com suas próprias vantagens - você pode usar qualquer uma delas:

1. Verifique e rejeite o código não conforme no check-in ou na compilação automatizada.
2. Edição automatizada de código para corrigir tags no check-in ou na criação automatizada.

Vale a pena tê-lo? Sim. Vale a pena 2 horas do seu tempo? Sua chamada.