¿Deberían anotarse los métodos del ciclo de vida de Unity con el atributo UsedImplicitly?

¿Anotar los métodos del ciclo de vida de Unity con el UsedImplicitlyatributo mejora la legibilidad de su código?

Por ejemplo:

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

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

Esta publicación de blog sobre "Estructurando su unidad de monocomportamientos" sugiere este enfoque como una convención útil.

8. Anote cualquier método de ciclo de vida de Unity (Inicio, Despertar, Actualizar, OnDestroy, etc.), métodos de eventos y otras funciones que se invoquen implícita (o automáticamente) en su código con el atributo [UsedImplicitly]. ReSharper utiliza este atributo, aunque está incluido en UnityEngine.dll, para deshabilitar las sugerencias de limpieza de código para métodos que aparentemente no tienen referencia. También ayuda a que el código sea más fácil de leer para las personas que son más nuevas en Unity y su base de código, especialmente para los eventos a los que se hace referencia a través del inspector.

(Nota: no creo que ReSharper muestre sugerencias de limpieza de código para métodos de ciclo de vida de Unity aparentemente sin referencia, por lo que podría ser un consejo desactualizado).

Estoy de acuerdo con la publicación anterior de que podría ser útil para los más nuevos en Unity. También creo que podría ser útil para etiquetar las funciones del ciclo de vida de la unidad de que no se utilizan con tanta frecuencia como Awake, Start, y Update. Pero me pregunto si esta es realmente una buena convención para el "código limpio", o si es solo el ruido lo que reduce la legibilidad.

Depende del objetivo demográfico.

En el ejemplo anterior, el objetivo demográfico es la herramienta ReSharper, que se beneficia de estos atributos porque suprime los mensajes que no son útiles para usted. Pero si no siente la necesidad de usar ReSharper o una herramienta similar (aunque tal vez debería hacerlo, tienen alguna crítica válida de vez en cuando), entonces no necesita preocuparse por esa demografía.

Cualquiera que haya hecho un tutorial básico de Unity sabe muy bien que Start y Updateel motor de Unity lo utiliza implícitamente, por lo que no les dará ninguna información nueva. De hecho, podría confundirlos si se olvida esto una vez. ¿Qué quieres decir con eso? ¿Es esto quizás no realmente un MonoBehaviour? ¿O hay alguna razón oscura por la que debes llamarla explícitamente de la que no estoy al tanto?

Sin embargo, puede ayudar si está trabajando con desarrolladores inexpertos que podrían no estar familiarizados con los eventos de Unity más esotéricos como Reset(peligroso, porque llamarlo explícitamente podría no hacer lo que cree que hace). El [UsedImplicitly]atributo podría decirles que no necesitan buscar la clase que llama a ese método porque el motor sí. Pero, de nuevo, esto solo tiene valor si tiene la disciplina para hacerlo de manera consistente. Y si tiene esa cantidad de autodisciplina, podría estar de acuerdo en agregar un comentario.

Sostengo que no, no deberías usarlo.

El atributo UsedImplicitly es del espacio de nombres Jetbrains.Annotations, por lo que el único caso en el que podría aplicarse es si todos los que usan el código usarán ReSharper.

ReSharper tiene un complemento para Unity que ya maneja esto por usted, asegurándose no solo de eliminar las advertencias de que no se usan, sino que también los marca con un pequeño símbolo de Unity para que cualquiera que lea el código pueda ver que Unity los llamó.

También me gustaría agregar un ejemplo cuando usarlos podría salir mal. Suponga que tiene una clase que hereda de MonoBehaviour, pero después de un refactorizador ya no tiene ninguna herencia. Si marcó métodos privados con [UsedImplicitly], no recibirá las advertencias correctas. Si usa el complemento Unity para reorganizador, notará que ya no hereda de MonoBehaviour y lanzará advertencias ya que los métodos ya no se llaman.

Argumentaría que realmente no puede doler.

Para alguien muy familiarizado con el funcionamiento de Unity, probablemente no agrega nada. Esas personas ya van a estar bastante familiarizadas con lo que el tiempo de ejecución de Unity llama en su nombre.

Pero para alguien que no es, como yo, podría ser útil. Incluso si no supiera lo que significaba de improviso, iría a buscarlo, y eso probablemente sería suficiente para comprender mejor lo que estaba sucediendo en el código.

Además, si uno usa herramientas de análisis estático que advierten incorrectamente sobre los métodos, entonces querrá silenciar esas advertencias de alguna manera, porque el ruido de advertencia "ignorable" hace que sea más difícil ver las advertencias reales en cualquier salida de este tipo. Por lo general, es mejor ignorar tales advertencias de manera quirúrgica y localizada (en este caso decorando los métodos ofensivos con atributos) que a través de medidas más amplias como deshabilitar esa advertencia específica en todo el proyecto.

El problema con este enfoque es que es increíblemente propenso a errores.

Si no es confiable, las etiquetas no transmitirán información útil, y su presencia o ausencia ocasionalmente logrará transmitir información falsa, lo cual es dañino.

Si decide seguirlo, debe eliminar el error humano, que no es difícil de hacer, pero lleva unas buenas 2 horas de trabajo si no ha hecho algo como esto antes. Hay 2 enfoques, cada uno con sus propias ventajas, puede usar cualquiera de ellos:

1. Verifique y rechace el código que no cumple al registrarse o la compilación automatizada.
2. Edición automatizada de código para corregir etiquetas en el check-in o compilación automática.

¿Vale la pena tenerlo? Si. ¿Vale la pena 2 horas de tu tiempo? Tu llamada.