Чи існує остаточна умова іменування методів повернення IAsyncEnumerable?

Після того, як C # 5 представила asyncта awaitмодель для асинхронного програмування, спільнота C # придумала конвенцію про іменування, щоб додати суфікс "Async" до методів повернення очікуваного типу, як-от:

interface Foo
{
   Task BarAsync();
}

Багато аналізаторів статичного коду (як на основі Росліна, так і не на основі Росліна) були написані, щоб залежати від цього правила іменування при виявленні запаху коду навколо асинхронного програмування.

Тепер, коли C # 8 ввів концепцію асинхронних перелічених даних, які самі по собі не є очікуваними, але можуть використовуватися спільно з await foreach, мабуть, існує два варіанти повернення методів іменування IAsyncEnumerable:

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

або

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

Чи існував остаточний настанов щодо конвенції про іменування (від мовної команди C #, фонду .NET Foundation чи інших органів) стосовно вищезазначених варіантів, як, наприклад, як конвенція про іменування C # 5 була однозначно стандартизована та не залишалася на судженнях програмістів на основі думки?

Немає кращого керівництва, ніж те, що вже роблять команди .NET :

• ChannelReader.ReadAllAsync повертаєIAsyncEnumerable<T>
• У EF Core 3 результати повертаються як IAsyncEnumerableвиклик AsAsyncEnumerable ()
• У System.Linq.Async ToAsyncEnumerable () перетворює IENumrablesbles, Tasks and Observables у IAsyncEnumerables
• Усі інші оператори System.Linq.Asyncзберігають свої назви. Немає SelectAsyncабо SelectAsAsyncEnumerable, просто Select.

У всіх випадках зрозуміло, який результат методу. У всіх випадках результатів методу потрібно чекати, await foreachперш ніж їх можна використовувати.

Тож справжнє керівництво залишається тим самим - переконайтеся, що ім’я чітко пояснює поведінку :

• Коли ім’я вже зрозуміло, наприклад, з AsAsyncEnumerable()або ToAsyncEnumerable(), немає потреби додавати суфікс.
• В інших випадках додайте Asyncсуфікс, щоб розробники знали, що їм потрібен await foreachрезультат.

Аналізатори коду та генератори насправді не хвилюються назви методів, вони виявляють запахи, перевіряючи сам код. Аналізатор коду покаже вам , що ви забули не чекати Завдання або незалежно від того , як ви називаєте методи і змінні. Генератор може просто використовувати відображення для перевірки та випромінюванняawait foreachIAsyncEnumerableIAsyncEnumerableawait foreach

Саме аналізатори стилів перевіряють назви. Їх завдання полягає в тому, щоб код використовував послідовний стиль, щоб розробники могли зрозуміти код. Аналізатор стилів скаже вам, що метод не відповідає обраному вами стилю. Цей стиль може бути керівництвом команди або загальноприйнятим посібником зі стилів.

І звичайно, всі знають, що загальний префікс для приватних полів екземплярів: _:)

Це не метод асинхронізації, тому ім'я не повинно закінчуватися "Async". Цей суфікс методу є умовою, щоб зробити очевидним, що методу слід чекати або результат обробляти як завдання.

Я думаю, що нормальна назва, що повертає колекцію, доречна. GetFoos () або подібне.

Суфікс Async і навіть ключове слово async- це лише плитка, це безглуздо, крім деяких аргументів зворотної порівняльності. C # має всю інформацію для розрізнення цих функцій так само, як це відрізняє yieldу методах, які повертаються IEnumerable, оскільки ви знаєте, що вам не потрібно додавати нічого подібного enumerableабо іншого ключового слова до таких методів.

Суфікс Async потрібно додати лише тому, що C # буде скаржитися на перевантаження, тому по суті ці два ідентичні, і вони роблять те саме за всіма правилами поліморфізму (якщо ми не беремо до уваги людський фактор навмисно корупціонерної поведінки):

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

Але ви не можете написати це так, оскільки компілятор буде скаржитися. Але, ей! Це проковтне цю жахливість:

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

і навіть це:

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

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

Так це воно. Ви додаєте Async просто для того, щоб зупинити компілятор, щоб скаржитися. Не для уточнення речей. Щоб не зробити їх кращими. Якщо немає скарги - немає причини її додавати, тож у вашому випадку я цього уникну, якщо не стане Task<IAsyncEnumerable>.

PS: Просто для кращого розуміння всієї картини тут - якщо колись у майбутньому хтось додасть розширення квантово-комп’ютерного методу C # (фантазія, так), які будуть працювати в різній парадигмі, нам, мабуть, знадобиться інший суфікс на кшталт Quant або щось подібне, тому що C # поскаржиться інакше. Це буде точно такий же метод, але це зробить це по-іншому. Так само, як це робить поліморфізм. Як і інтерфейси.