Sollten Unity-Lebenszyklusmethoden mit dem Attribut UsedImplicitly versehen werden?


9

UsedImplicitlyVerbessert das Annotieren von Unity-Lebenszyklusmethoden mit dem Attribut die Lesbarkeit Ihres Codes?

Zum Beispiel:

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

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

Dieser Blog-Beitrag über "Strukturieren Ihrer Einheit MonoBehaviours" schlägt diesen Ansatz als nützliche Konvention vor.

  1. Kommentieren Sie alle Unity-Lebenszyklusmethoden (Start, Awake, Update, OnDestroy usw.), Ereignismethoden und andere Funktionen, die implizit (oder automatisch) in Ihrem Code aufgerufen werden, mit dem Attribut [UsedImplicitly]. Obwohl dieses Attribut in der UnityEngine.dll enthalten ist, wird es von ReSharper verwendet, um Vorschläge zur Codebereinigung für Methoden zu deaktivieren, auf die scheinbar nicht verwiesen wird. Dies erleichtert auch das Lesen des Codes für Personen, die mit Unity und Ihrer Codebasis noch nicht vertraut sind, insbesondere für Ereignisse, auf die über den Inspektor verwiesen wird.

(Hinweis: Ich glaube nicht, dass ReSharper Vorschläge zur Codebereinigung für scheinbar nicht referenzierte Unity-Lebenszyklusmethoden anzeigt, sodass dies möglicherweise veraltete Ratschläge sind.)

Ich stimme dem obigen Beitrag zu, dass er für diejenigen hilfreich sein könnte, die neu in Unity sind. Ich denke auch , es könnte nützlich sein , diese zu beschriften Unity Lifecycle - Funktionen , die nicht so häufig verwendet werden , wie Awake, Startund Update. Aber ich frage mich, ob dies tatsächlich eine gute Konvention für "sauberen Code" ist oder ob nur Rauschen die Lesbarkeit beeinträchtigt.


1
Ich habe 2 Spiele in Unity veröffentlicht und wusste nicht, dass dies existiert. Wenn ich das getan hätte, hätte ich es wahrscheinlich aus Gründen der Klarheit verwendet und würde es nicht als Lärm betrachten.
McAden

1
Hey, ich bin der ursprüngliche Autor des Beitrags. Ja, ich denke, es kann für Lebenszyklusmethoden ein Overkill sein, insbesondere angesichts der verbesserten Resharper-Unterstützung. Ich denke jedoch, dass es nützlich ist, Ereignisrückrufe (z. B. für Animationen und das UI-Ereignissystem von Unity) mit Anmerkungen zu versehen, auf die nur über den Inspektor verwiesen wird. Es liegt jedoch an den Leuten, die die Codebasis verwalten - als ich dies schrieb, arbeitete ich bei einem Software-Beratungsunternehmen, bei dem niemand Erfahrung mit Spieleentwicklern hatte, und wollte daher einen Standard zwischen uns etablieren. Rückblickend ist es ein bisschen drakonisch, da ich nicht damit gerechnet habe, dass der Beitrag Aufmerksamkeit erregt.
Mana

Antworten:


10

Dies hängt von der Zielgruppe ab.

Im obigen Beispiel ist die Zielgruppe das ReSharper-Tool, das von diesen Attributen profitiert, da es Nachrichten unterdrückt, die für Sie nicht hilfreich sind. Wenn Sie jedoch nicht das Bedürfnis haben, ReSharper oder ein ähnliches Tool zu verwenden (obwohl Sie es vielleicht sollten, haben sie von Zeit zu Zeit eine gültige Kritik), müssen Sie sich nicht um diese demografische Gruppe kümmern.

Jeder, der jemals ein grundlegendes Unity-Tutorial erstellt hat, weiß das sehr gut Startund Updatewird implizit von der Unity-Engine verwendet, sodass er keine neuen Informationen erhält. Es könnte in der Tat die Hölle verwirren, wenn Sie dies einmal vergessen. Was willst du damit sagen? Ist das vielleicht nicht wirklich ein MonoBehaviour? Oder gibt es einen obskuren Grund, warum Sie es explizit nennen müssen, den ich nicht kenne?

Es kann jedoch hilfreich sein, wenn Sie mit unerfahrenen Entwicklern zusammenarbeiten, die möglicherweise nicht mit den eher esoterischen Unity-Ereignissen vertraut sind Reset(gefährlich, da ein expliziter Aufruf möglicherweise nicht das tut, was Sie denken). Das [UsedImplicitly]Attribut sagt ihnen dann möglicherweise, dass sie nicht nach der Klasse suchen müssen, die diese Methode aufruft, weil die Engine dies tut. Aber auch dies ist nur dann von Wert, wenn Sie die Disziplin haben, dies konsequent zu tun. Und wenn Sie so viel Selbstdisziplin haben, können Sie sich genauso gut darauf einigen, einen Kommentar hinzuzufügen.


1
Ich würde hinzufügen, "für 99% der Demografie bietet es keinen Nutzen". Selbst Anfänger werden nach wenigen Stunden beginnen, Lebenszyklusmethoden zu erkennen (sie sind in VS unterschiedlich gefärbt!). Und Resharper ist: Eine teure Lizenz kann neu konfiguriert werden, und wie OP sagte, ist sie wahrscheinlich sowieso schon gepatcht. Ich denke, man kann seine Zeit effektiver verbringen, als jede zweite Methode mit Attributen von streitbarem Wert zu dekorieren.
Wondra

@wondra Vielen Dank, dass Sie darauf hingewiesen haben, dass sie in Visual Studio unterschiedlich gefärbt sind. Ich werde versuchen herauszufinden, warum dies mit Visual Studio 2017 für mich nicht funktioniert, obwohl Tools -> Options -> Tools for Unity -> General -> Unity Messages syntax highlightinges auf true gesetzt ist.
Sonny

1
Ich habe nicht untersucht, warum Visual Studio meine Unity-Methoden nicht färbt, aber eine andere Antwort wies darauf hin, dass ReSharper ein Plugin für Unity hat, das auch Unity-Ereignisfunktionen automatisch erkennt. Es gibt auch diese verwandte Einstellung : ReSharper -> Options -> Code Inspection -> Settings -> Enable code analysis -> Color identifiers.
Sonny

6

Ich behaupte, nein, du solltest es nicht benutzen.

Das UsedImplicitly-Attribut stammt aus dem Jetbrains.Annotations-Namespace. Der einzige Fall, in dem es möglicherweise angewendet wird, ist, wenn jeder, der den Code verwendet, ReSharper verwendet.

ReSharper hat ein Plugin für Unity, das dies bereits für Sie erledigt. Achten Sie darauf, dass Sie nicht nur Warnungen entfernen, die nicht verwendet werden, sondern sie auch mit einem kleinen Unity-Symbol kennzeichnen, damit jeder, der den Code liest, sehen kann, dass sie von Unity selbst aufgerufen werden.

Ich möchte auch ein Beispiel hinzufügen, wenn die Verwendung möglicherweise schief geht. Angenommen, Sie haben eine Klasse, die von MonoBehaviour erbt, aber nach einem Refactor hat sie keine Vererbung mehr. Wenn Sie private Methoden mit [UsedImplicitly] markiert haben, erhalten Sie nicht die richtigen Warnungen. Wenn Sie das Unity-Plugin zum erneuten Schärfen verwenden, wird festgestellt, dass Sie nicht mehr von MonoBehaviour erben, und es werden Warnungen ausgegeben, da die Methoden tatsächlich nicht mehr aufgerufen werden.


1
Mir war nicht bewusst, dass das ReSharper-Plugin existiert, danke, dass Sie darauf hingewiesen haben!
Sonny

1
Beachten Sie, dass Unity ab Unity 5 damit begonnen hat, die ReSharper-Attribute in UnityEngine.dll aufzunehmen - siehe diesen Forumsbeitrag .
Sonny

5

Ich würde argumentieren, dass es nicht wirklich weh tun kann.

Für jemanden, der mit der Arbeitsweise von Unity sehr vertraut ist, fügt es wahrscheinlich nichts hinzu. Diese Leute werden bereits ziemlich vertraut damit sein, was die Laufzeit von Unity in Ihrem Namen erfordert.

Aber für jemanden, der nicht so ist wie ich, könnte es hilfreich sein. Selbst wenn ich nicht sofort wüsste, was es bedeutet, würde ich es nachschlagen, und das würde wahrscheinlich ausreichen, um mir ein besseres Verständnis dafür zu geben, was im Code vor sich geht.

Wenn man statische Analysewerkzeuge verwendet, die fälschlicherweise vor den Methoden warnen, sollten Sie diese Warnungen irgendwie beruhigen, da "ignorierbares" Warngeräusch es schwieriger macht, die tatsächlichen Warnungen in einer solchen Ausgabe zu sehen. In der Regel ist es besser, solche Warnungen auf chirurgische, lokalisierte Weise zu ignorieren (in diesem Fall durch Verzieren der fehlerhaften Methoden mit Attributen), als durch umfassendere Maßnahmen wie das Deaktivieren dieser spezifischen Warnung im gesamten Projekt.


1
Danke für deine Antwort. Ich habe ähnlich gedacht wie Ihre Antwort, als ich die Frage gepostet habe, aber ich stimme anderen Postern zu, die darauf hinweisen, dass es möglicherweise irreführend sein kann, wenn das Attribut nicht konsistent verwendet wird.
Sonny

3
Ja, das sind faire Punkte. Wenn man sich die statische Analyse haben , dass Fahrten über diese und behandelt man ernsthaft diese Warnungen, dass Sie das Attribut dazu beitragen kann , wird gleichmäßig aufgetragen. Aber wenn nicht? Dann liegt es ziemlich am menschlichen Versagen.

2

Das Problem bei diesem Ansatz ist, dass er unglaublich fehleranfällig ist.

Wenn dies nicht zuverlässig ist, können die Tags keine nützlichen Informationen übermitteln, und ihre Anwesenheit oder Abwesenheit kann gelegentlich falsche Informationen übermitteln, was schädlich ist.

Wenn Sie sich dafür entscheiden, müssen Sie den menschlichen Fehler beseitigen, was nicht schwer zu tun ist, aber gut 2 Stunden Arbeit kostet, wenn Sie so etwas noch nicht getan haben. Es gibt zwei Ansätze - jeder mit seinen eigenen Vorteilen - Sie können einen verwenden:

  1. Überprüfen und lehnen Sie nicht konformen Code beim Einchecken oder beim automatisierten Erstellen ab.
  2. Automatisierte Bearbeitung von Code zum Korrigieren von Tags beim Einchecken oder beim automatischen Erstellen.

Lohnt es sich, es zu haben? Ja. Lohnt es sich 2 Stunden Ihrer Zeit? Ihr Anruf.


1
Ich habe eine andere Antwort akzeptiert, aber Sie legen großen Wert darauf, den menschlichen Fehler für alle zu beseitigen, die darüber nachdenken, das UsedImplicitlyAttribut für diesen Zweck zu verwenden.
Sonny
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.