Gibt es eine definitive Namenskonvention für Methoden, die IAsyncEnumerable zurückgeben?

Nachdem C # 5 das asyncund await-Modell für die asynchrone Programmierung eingeführt hatte, gelangte die C # -Community zu einer Namenskonvention, um Methoden, die einen erwarteten Typ zurückgeben, ein "Async" -Suffix hinzuzufügen:

interface Foo
{
   Task BarAsync();
}

Viele statische Codeanalysatoren (sowohl Roslyn-basiert als auch nicht Roslyn-basiert) wurden seitdem so geschrieben, dass sie von dieser Namenskonvention abhängen, wenn Codegeruch bei asynchroner Programmierung erkannt wird.

Nachdem C # 8 das Konzept der asynchronen Aufzählungen eingeführt hat, die selbst nicht zu erwarten sind, aber in Verbindung mit verwendet werden können await foreach, scheint es zwei Optionen für die Rückgabe von Benennungsmethoden zu geben IAsyncEnumerable:

interface Foo
{
    // No "Async" suffix, indicating that the return value is not awaitable.
    IAsyncEnumerable<T> Bar<T>();
}

oder

interface Foo
{
    // With "Async" suffix, indicating that the overall logic is asynchronous.
    IAsyncEnumerable<T> BarAsync<T>();
}

Gab es eine endgültige Richtlinie für Namenskonventionen (vom C # -Sprachteam, der .NET Foundation oder anderen Behörden) zu den oben genannten Optionen, z. B. wie die C # 5-Namenskonvention eindeutig standardisiert und nicht der meinungsbasierten Beurteilung von Programmierern überlassen wurde?

Es gibt keine bessere Richtlinie als das, was die .NET-Teams bereits tun:

• ChannelReader.ReadAllAsync gibt eine zurückIAsyncEnumerable<T>
• In EF Core 3 werden die Ergebnisse IAsyncEnumerabledurch Aufrufen von AsAsyncEnumerable () als zurückgegeben
• In System.Linq.Async konvertiert ToAsyncEnumerable () IEnumerables, Tasks und Observables in IAsyncEnumerables
• Alle anderen Betreiber System.Linq.Asyncbehalten ihre Namen. Es gibt kein SelectAsyncoder SelectAsAsyncEnumerablenur Select.

In allen Fällen ist klar, was das Ergebnis der Methode ist. In allen Fällen müssen die Ergebnisse der Methode abgewartet werden, await foreachbevor sie verwendet werden können.

Die eigentliche Richtlinie bleibt also dieselbe - stellen Sie sicher, dass der Name das Verhalten klar macht :

• Wenn der Name bereits klar ist, z. B. mit AsAsyncEnumerable()oder ToAsyncEnumerable(), muss kein Suffix hinzugefügt werden.
• In anderen Fällen fügen Sie das AsyncSuffix hinzu, damit Entwickler wissen, dass sie await foreachdas Ergebnis benötigen .

Die Code-Analysatoren und -Generatoren kümmern sich nicht wirklich um die Namen der Methoden, sie erkennen Gerüche, indem sie den Code selbst untersuchen. Ein Code - Analyse wird Ihnen sagen , dass Sie eine Aufgabe oder zu erwarten vergessen await foreachein IAsyncEnumerableganz gleich , wie Sie die Methoden aufrufen und die Variablen. Ein Generator kann einfach Reflexion verwenden, um zu prüfen IAsyncEnumerableund zu emittierenawait foreach

Es ist die Art Analysatoren , die Namen überprüfen. Ihre Aufgabe ist es, sicherzustellen, dass der Code einen konsistenten Stil verwendet, damit Entwickler den Code verstehen können. Der Stilanalysator teilt Ihnen mit, dass eine Methode nicht dem von Ihnen gewählten Stil folgt. Dieser Stil kann der des Teams oder ein allgemein akzeptierter Styleguide sein.

Und natürlich weiß jeder, dass das übliche Präfix für private Instanzfelder _:) ist.

Es ist keine asynchrone Methode, daher sollte der Name nicht mit "Async" enden. Dieses Methodensuffix ist eine Konvention, um deutlich zu machen, dass auf die Methode gewartet oder das Ergebnis als Aufgabe behandelt werden sollte.

Ich denke, ein normaler Sammlungsname ist angemessen. GetFoos () oder ähnliches.

Asynchrones Suffix und sogar Schlüsselwort asyncsind nur Boilerplate, es ist bedeutungslos, abgesehen von einigen Argumenten der Abwärtskompatibilität. C # verfügt über alle Informationen, um diese Funktionen zu unterscheiden, genau wie es sich yieldbei Methoden unterscheidet, die zurückgeben IEnumerable, da Sie wissen, dass Sie enumerablesolchen Methoden kein ähnliches oder ein anderes Schlüsselwort hinzufügen müssen .

Sie müssen das Async- Suffix hinzufügen, nur weil C # sich über Überlastungen beschwert. Daher sind diese beiden im Wesentlichen identisch und tun nach allen Regeln des Polymorphismus dasselbe (wenn wir den menschlichen Faktor der intakten Korruption des Verhaltens nicht berücksichtigen):

public interface IMyContract
{
    Task<int> Add(int a, int b);
    int Add(int a, int b);
}

Aber Sie können es nicht so schreiben, weil sich der Compilator beschweren wird. Aber hey! Es wird diese eine Monstrosität verschlucken:

public interface IMyContract : IEnumerable<int>, IEnumerable<long>
{
}

und sogar das:

public interface IMyContractAsync
{
    Task<int> Add(int a, int b);
}

public interface IMyContract : IMyContractAsync
{
    int Add(int a, int b);
}

So, das ist es. Sie fügen Async hinzu , um den Compiler zu stoppen und sich zu beschweren. Dinge nicht zu klären. Nicht um sie besser zu machen. Wenn es keine Beschwerde gibt - kein Grund, sie hinzuzufügen, werde ich dies in Ihrem Fall vermeiden, es sei denn, es wird Task<IAsyncEnumerable>.

PS: Nur um das gesamte Bild hier besser zu verstehen - wenn irgendwann in Zukunft jemand C # -Quantencomputer-Methodenerweiterungen (fantasazy, huh) hinzufügt, die in einem anderen Paradigma funktionieren, werden wir wahrscheinlich ein anderes Suffix wie Quant oder so brauchen , weil C # werde mich sonst beschweren. Es wird genau die gleiche Methode sein, aber es wird anders funktionieren. Genau wie Polymorphismus. Genau wie Schnittstellen.