I metodi del ciclo di vita di Unity devono essere annotati con l'attributo UsedImplicitly?

L'annotazione dei metodi del ciclo di vita di Unity con l' UsedImplicitlyattributo migliora la leggibilità del codice?

Per esempio:

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

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

Questo post sul blog "Structuring Your Unity MonoBehaviours" suggerisce questo approccio come una convenzione utile.

8. Annota tutti i metodi del ciclo di vita di Unity (Start, Awake, Update, OnDestroy ecc.), I metodi di evento e altre funzioni che sono implicitamente (o automaticamente) invocate nel tuo codice con l'attributo [UsedImplicitly]. Questo attributo, sebbene incluso in UnityEngine.dll, viene utilizzato da ReSharper per disabilitare i suggerimenti di pulizia del codice per metodi apparentemente senza riferimenti. Aiuta anche a rendere il codice più facile da leggere per le persone che sono più recenti su Unity e sul tuo codebase, in particolare per gli eventi a cui si fa riferimento tramite l'ispettore.

(Nota: non credo che ReSharper mostri suggerimenti per la pulizia del codice per metodi del ciclo di vita di Unity apparentemente senza riferimenti, quindi potrebbero essere consigli obsoleti.)

Sono d'accordo con il post sopra che potrebbe essere utile per i più recenti su Unity. Ritengo inoltre che potrebbe essere utile per etichettare le funzioni del ciclo di vita Unity che non vengono utilizzati frequentemente come Awake, Starte Update. Ma mi chiedo se questa sia effettivamente una buona convenzione per "codice pulito", o se è solo il rumore che riduce la leggibilità.

Dipende dal target demografico.

Nell'esempio sopra, il target demografico è lo strumento ReSharper, che beneficia di questi attributi perché sopprime i messaggi che non ti sono utili. Ma se non senti la necessità di usare ReSharper o uno strumento simile (anche se forse dovresti, di tanto in tanto hanno qualche critica valida), allora non devi preoccuparti di quel dato demografico.

Chiunque abbia mai fatto un tutorial di base su Unity lo sa molto bene Starte Updateviene utilizzato implicitamente dal motore Unity, quindi non fornirà loro nuove informazioni. Potrebbe infatti confondere il diavolo se li dimentichi una volta. Che cosa vuoi dire con quello? Questo non è forse un comportamento monocromatico? O c'è qualche oscura ragione per cui devi chiamarlo esplicitamente di cui non sono a conoscenza?

Può, tuttavia, aiutare se stai lavorando con sviluppatori inesperti che potrebbero non avere familiarità con gli eventi Unity più esoterici come Reset(pericoloso, perché chiamarlo esplicitamente potrebbe non fare quello che pensi che faccia). L' [UsedImplicitly]attributo potrebbe quindi dire loro che non hanno bisogno di cercare la classe che chiama quel metodo perché il motore lo fa. Ma ancora una volta, questo ha valore solo se hai la disciplina per farlo in modo coerente. E se hai quell'autodisciplina, puoi anche concordare di aggiungere un commento.

Sostengo che no, non dovresti usarlo.

L'attributo UsedImplicitly proviene dallo spazio dei nomi Jetbrains.Annotations, quindi l'unico caso in cui potrebbe essere applicato è se tutti gli utenti del codice utilizzeranno ReSharper.

ReSharper ha un plugin per Unity che lo gestisce già per te, assicurandosi non solo di rimuovere gli avvisi che non vengono utilizzati, ma anche di contrassegnarli con un piccolo simbolo Unity in modo che chiunque legga il codice possa vedere che sono chiamati da Unity stesso.

Vorrei anche aggiungere un esempio quando usarli potrebbe andare storto. Supponi di avere una classe che eredita da MonoBehaviour, ma dopo un refactor non ha più eredità. Se hai contrassegnato i metodi privati ​​con [UsedImplicitly], non riceverai gli avvisi corretti. Se si utilizza il plug-in Unity per il resharper, si noterà che non si eredita più da MonoBehaviour e verranno emessi avvisi poiché i metodi in effetti non vengono più chiamati.

Direi che non può far male davvero.

Per qualcuno che ha molta familiarità con il funzionamento di Unity, probabilmente non aggiunge nulla. Quelle persone avranno già abbastanza familiarità con ciò che il runtime di Unity chiama per tuo conto.

Ma per qualcuno che non lo è, come me, potrebbe essere utile. Anche se non sapessi cosa significasse in modo diretto, andrei a cercarlo, e questo sarebbe probabilmente sufficiente per darmi una migliore comprensione di ciò che stava accadendo nel codice.

Inoltre, se si utilizzano strumenti di analisi statica che avvisano in modo errato dei metodi, si consiglia di mettere a tacere quegli avvisi in qualche modo, perché il rumore di avviso "ignorabile" rende più difficile la visualizzazione degli avvisi reali in tali output. Di solito è meglio ignorare tali avvisi in modo chirurgico e localizzato (in questo caso decorando i metodi offensivi con attributi) piuttosto che attraverso misure più ampie come la disabilitazione di tale specifico avviso a livello di progetto.

Il problema con questo approccio è che è incredibilmente soggetto a errori.

Se non è affidabile, i tag non riusciranno a trasmettere informazioni utili e la loro presenza o assenza riuscirà occasionalmente a trasmettere informazioni false, il che è dannoso.

Se decidi di seguirlo, devi rimuovere l'errore umano, che non è difficile da fare, ma richiede ben 2 ore di lavoro se non hai mai fatto qualcosa di simile prima. Esistono 2 approcci - ognuno con i propri vantaggi - è possibile utilizzare uno di questi:

1. Verifica e rifiuta il codice non conforme al momento del check-in o della build automatizzata.
2. Modifica automatica del codice per correggere i tag al momento del check-in o build automatizzata.

Vale la pena averlo? Sì. Vale 2 ore del tuo tempo? La tua chiamata.