Les méthodes de cycle de vie Unity doivent-elles être annotées avec l'attribut UsedImplicitly?

L'annotation des méthodes de cycle de vie Unity avec l' UsedImplicitlyattribut améliore-t-elle la lisibilité de votre code?

Par exemple:

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

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

Ce billet de blog sur "Structurer vos comportements uniques" suggère cette approche comme une convention utile.

8. Annotez toutes les méthodes de cycle de vie Unity (Start, Awake, Update, OnDestroy etc.), les méthodes d'événement et d'autres fonctions qui sont implicitement (ou automatiquement) invoquées dans votre code avec l'attribut [UsedImplicitly]. Cet attribut, bien qu'il soit inclus dans UnityEngine.dll, est utilisé par ReSharper pour désactiver les suggestions de nettoyage de code pour les méthodes qui ne semblent pas référencées. Cela aide également à rendre le code plus facile à lire pour les personnes qui sont plus récentes à Unity et à votre base de code, en particulier pour les événements référencés via l'inspecteur.

(Remarque: je ne pense pas que ReSharper affiche des suggestions de nettoyage de code pour des méthodes de cycle de vie Unity apparemment non référencées, ce qui pourrait être un conseil obsolète.)

Je suis d'accord avec le post ci-dessus qu'il pourrait être utile pour les nouveaux utilisateurs d'Unity. Je pense aussi qu'il pourrait être utile d'étiqueter les fonctions du cycle de vie Unity qui ne sont pas utilisés aussi fréquemment que Awake, Startet Update. Mais je me demande si c'est en fait une bonne convention pour le "code propre", ou si c'est juste du bruit qui réduit la lisibilité.

Cela dépend de la démographie cible.

Dans l'exemple ci-dessus, le groupe démographique cible est l'outil ReSharper, qui bénéficie de ces attributs car il supprime les messages qui ne vous sont pas utiles. Mais si vous ne ressentez pas le besoin d'utiliser ReSharper ou un outil similaire (bien que vous le deviez peut-être, ils ont parfois des critiques valables), alors vous n'avez pas besoin de vous soucier de cette démographie.

Quiconque a déjà fait un didacticiel de base sur Unity le sait très bien Startet Updateest utilisé implicitement par le moteur Unity, il ne leur donnera donc aucune nouvelle information. En fait, cela pourrait les confondre si vous les oubliez une fois. Que voulez-vous dire avec ça? N'est-ce pas peut-être en fait un MonoBehaviour? Ou y a-t-il une raison obscure pour laquelle vous devez l'appeler explicitement que je ne connais pas?

Cependant, cela peut être utile si vous travaillez avec des développeurs inexpérimentés qui pourraient ne pas être familiers avec les événements Unity plus ésotériques comme Reset(dangereux, car l'appeler explicitement pourrait ne pas faire ce que vous pensez qu'il fait). L' [UsedImplicitly]attribut pourrait alors leur dire qu'ils n'ont pas besoin de rechercher la classe qui appelle cette méthode car le moteur le fait. Mais encore une fois, cela n'a de valeur que si vous avez la discipline de le faire de manière cohérente. Et si vous avez une telle autodiscipline, vous pourriez tout aussi bien convenir d'ajouter un commentaire.

Je soutiens que non, vous ne devriez pas l'utiliser.

L'attribut UsedImplicitly provient de l'espace de noms Jetbrains.Annotations, donc le seul cas où il pourrait s'appliquer est si tout le monde utilisant le code utilisera ReSharper.

ReSharper a un plugin pour Unity qui gère déjà cela pour vous, en veillant non seulement à supprimer les avertissements qu'ils ne sont pas utilisés, mais également à les marquer avec un petit symbole Unity afin que toute personne lisant le code puisse voir qu'ils sont appelés par Unity lui-même.

Je voudrais également ajouter un exemple lorsque leur utilisation pourrait mal tourner. Supposons que vous ayez une classe héritant de MonoBehaviour, mais après un refactor, elle n'a plus d'héritage. Si vous avez marqué les méthodes privées avec [UsedImplicitly], vous ne recevrez pas les avertissements corrects. Si vous utilisez le plugin Unity pour resharper, il remarquera que vous n'héritez plus de MonoBehaviour et lancera des avertissements car les méthodes ne sont en effet plus appelées.

Je dirais que cela ne peut pas vraiment faire de mal.

Pour quelqu'un qui connaît très bien le fonctionnement d'Unity, cela n'ajoute probablement rien. Ces personnes vont déjà être assez familières avec ce que le runtime d'Unity appelle en votre nom.

Mais pour quelqu'un qui ne l'est pas, comme moi, cela pourrait être utile. Même si je ne savais pas ce que cela signifiait au hasard, j'irais le chercher, et ce serait probablement suffisant pour me donner une meilleure compréhension de ce qui se passait dans le code.

De plus, si l'on utilise des outils d'analyse statique qui avertissent incorrectement sur les méthodes, alors vous voudrez calmer ces avertissements d'une manière ou d'une autre, car le bruit d'avertissement "ignorable" rend plus difficile de voir les vrais avertissements dans une telle sortie. Il est généralement préférable d'ignorer ces avertissements de manière chirurgicale et localisée (dans ce cas, en décorant les méthodes incriminées avec des attributs) plutôt que par des mesures plus larges telles que la désactivation de cet avertissement spécifique à l'échelle du projet.

Le problème avec cette approche est qu'elle est incroyablement sujette aux erreurs.

S'il n'est pas fiable, les balises ne transmettront pas d'informations utiles et leur présence ou leur absence réussira parfois à transmettre de fausses informations, ce qui est dangereux.

Si vous décidez d'y aller, vous devez supprimer l'erreur humaine, ce qui n'est pas difficile à faire, mais prend 2 bonnes heures de travail si vous n'avez jamais fait quelque chose comme ça auparavant. Il existe 2 approches - chacune avec ses propres avantages - vous pouvez utiliser l'une ou l'autre:

1. Vérifiez et rejetez le code non conforme lors de l'enregistrement ou de la construction automatisée.
2. Modification automatisée du code pour corriger les balises lors de l'enregistrement ou de la construction automatisée.

Vaut-il la peine? Oui. Cela vaut-il 2 heures de votre temps? Ton appel.