L'utilisation du suffixe «Async» dans un nom de méthode dépend-elle de l'utilisation ou non du modificateur «async»?

Quelle est la convention pour suffixer les noms de méthodes avec "Async"?

Le suffixe "Async" doit-il être ajouté uniquement à une méthode déclarée avec le asyncmodificateur?

public async Task<bool> ConnectAsync()

Ou est-ce suffisant que la méthode retourne simplement Task<T>ou Task?

public Task<bool> ConnectAsync()

Je pense que la vérité est ambiguë même à partir de la documentation Microsoft:

Dans Visual Studio 2012 et .NET Framework 4.5, toute méthode attribuée avec le asyncmot clé ( Asyncdans Visual Basic) est considérée comme une méthode asynchrone, et les compilateurs C # et Visual Basic effectuent les transformations nécessaires pour implémenter la méthode de manière asynchrone à l'aide de TAP. Une méthode asynchrone doit renvoyer Taskun Task<TResult>objet ou un objet.

http://msdn.microsoft.com/en-us/library/hh873177(v=vs.110).aspx

Ce n'est pas déjà vrai. Toute méthode avec asyncest asynchrone et elle dit qu'elle doit retourner soit a Taskou Task<T>- ce qui n'est pas correct pour les méthodes en haut d'une pile d'appels, Button_Click par exemple, ou async void.

Bien sûr, vous devez vous demander quel est l’intérêt de la convention?

Vous pourriez dire que la Asyncconvention de suffixe est de communiquer à l'utilisateur de l'API que la méthode est attendue. Pour qu'une méthode soit attendue, elle doit retourner Taskpour un void, ou Task<T>pour une méthode de retour de valeur, ce qui signifie que seule cette dernière peut être suffixée Async.

Ou vous pourriez dire que la Asyncconvention de suffixe est de communiquer que la méthode peut retourner immédiatement, abandonnant le thread actuel pour effectuer un autre travail et provoquant potentiellement des courses.

Cette citation de Microsoft doc dit:

Par convention, vous ajoutez «Async» aux noms des méthodes qui ont un modificateur Async ou async.

http://msdn.microsoft.com/en-us/library/hh191443.aspx#BKMK_NamingConvention

Ce qui ne mentionne même pas que vos propres méthodes asynchrones retournant ont Taskbesoin du Asyncsuffixe, ce que je pense que nous sommes tous d'accord pour dire qu'ils le font.

La réponse à cette question pourrait donc être: les deux. Dans les deux cas, vous devez ajouter Asyncaux méthodes avec un asyncmot-clé et qui renvoie Taskou Task<T>.

Je vais demander à Stephen Toub de clarifier la situation.

Mettre à jour

Alors je l'ai fait. Et voici ce que notre brave homme a écrit:

Si une méthode publique renvoie une tâche et est de nature asynchrone (par opposition à une méthode connue pour s'exécuter toujours de manière synchrone jusqu'à la fin mais qui retourne toujours une tâche pour une raison quelconque), elle doit avoir un suffixe «Async». C'est la ligne directrice. Le but principal ici avec la dénomination est de rendre très évident pour un consommateur de la fonctionnalité que la méthode appelée ne terminera probablement pas tout son travail de manière synchrone; cela aide bien sûr également dans le cas où la fonctionnalité est exposée avec des méthodes synchrones et asynchrones, de sorte que vous avez besoin d'une différence de nom pour les distinguer. La manière dont la méthode réalise son implémentation asynchrone n'a pas d'importance pour la dénomination: si async / await est utilisé pour obtenir l'aide du compilateur, ou si les types et méthodes de System.Threading.Tasks sont utilisés directement (e. g. TaskCompletionSource) n'a pas vraiment d'importance, car cela n'affecte pas la signature de la méthode en ce qui concerne le consommateur de la méthode.

Bien sûr, il y a toujours des exceptions à une directive. Le plus notable dans le cas de la dénomination serait les cas où la raison d'être d'un type entier est de fournir des fonctionnalités axées sur l'async, auquel cas avoir Async sur chaque méthode serait excessif, par exemple les méthodes sur Task elle-même qui produisent d'autres tâches. .

En ce qui concerne les méthodes asynchrones à retour de vide, il n'est pas souhaitable de les avoir dans la zone publique, car l'appelant n'a aucun bon moyen de savoir quand le travail asynchrone est terminé. Cependant, si vous devez exposer publiquement une méthode asynchrone à retour vide, vous souhaiterez probablement avoir un nom qui indique que le travail asynchrone est en cours de lancement, et vous pouvez utiliser le suffixe «Async» ici si cela a du sens. Compte tenu de la rareté de ce cas, je dirais que c'est vraiment une décision au cas par cas.

J'espère que ça aide, Steve

Les conseils succincts de la phrase d'ouverture de Stephen sont assez clairs. Cela exclut async voidcar il est inhabituel de vouloir créer une API publique avec une telle conception, car la manière correcte d'implémenter un vide asynchrone est de retourner une Taskinstance simple et de laisser le compilateur faire sa magie. Cependant, si vous voulez un public async void, alors l'ajout Asyncest conseillé. D'autres async voidméthodes de haut de gamme telles que les gestionnaires d'événements ne sont généralement pas publiques et n'ont pas d'importance / ne sont pas qualifiées.

Pour moi, cela me dit que si je me pose des questions sur le suffixe Asyncsur un async void, je devrais probablement le transformer en un async Taskpour que les appelants puissent l'attendre, puis l'ajouter Async.

Je construis beaucoup de services API et d'autres applications qui appellent d'autres systèmes où la plupart de mon code s'exécute de manière asynchrone.

Ma propre règle de base que je suis:

S'il existe à la fois des méthodes non async et async qui renvoient la même chose, je suffixe l'async avec Async. Sinon non.

Exemples:

Une seule méthode:

public async Task<User> GetUser() { [...] }

Même méthode avec deux signatures:

public User GetUser() { [...] }

public async Task<User> GetUserAsync() { [...] }

Cela a du sens car ce sont les mêmes données qui sont renvoyées, mais la seule chose qui diffère est la manière de renvoyer les données , pas les données elles-mêmes.

Je pense également que ces conventions de dénomination existent en raison de la nécessité d'introduire des méthodes asynchrones tout en conservant la compatibilité ascendante.

Je soutiens que le nouveau code ne devrait pas utiliser le suffixe Async. C'est tout aussi évident que le type de retour String ou Int comme mentionné précédemment dans ce thread.

Quelle est la convention pour suffixer les noms de méthodes avec "Async".

Le modèle asynchrone basé sur les tâches (TAP) dicte que les méthodes doivent toujours renvoyer un Task<T>(ou Task) et être nommées avec un suffixe Async ; ceci est distinct de l'utilisation de async. Les deux Task<bool> Connect()et se compileront et fonctionneront très bien, mais vous ne suivrez pas la convention de dénomination TAP.asyncTask<bool> Connect()

La méthode devrait-elle contenir le asyncmodificateur, ou suffisamment pour qu'elle renvoie simplement Task?

Si le corps de la méthode (quel que soit le type ou le nom de retour) inclut await, vous devez utiliser async; et le compilateur vous dira "L'opérateur 'await' ne peut être utilisé que dans une méthode asynchrone. ...". Le retour Task<T>ou Taskn'est pas "suffisant" pour éviter d'utiliser async. Voir async (référence C #) pour plus de détails.

C'est à dire laquelle de ces signatures est correcte:

Les deux et respectent correctement les conventions TAP. Vous pouvez toujours utiliser le mot - clé, mais vous obtiendrez un avertissement du compilateur "Cette méthode asynchrone ne dispose pas des opérateurs 'await' et s'exécutera de manière synchrone. ..." si le corps ne l'utilise pas .asyncTask<bool> ConnectAsync()Task<bool> ConnectAsync()asyncawait

ou suffit-il qu'il renvoie simplement Task?

Cette. Le asyncmot clé n'est pas le vrai problème ici. Si vous implémentez l'asynchronie sans utiliser le asyncmot - clé, la méthode est toujours "Async", au sens général.

Depuis Tasket Task<T>sont tous deux des types attendables, ils représentent certains opération asynchrone. Ou du moins, ils devraient représenter.

Vous devez ajouter un suffixe Asyncà une méthode qui, dans certains cas (pas nécessairement tous), ne renvoie pas de valeur mais renvoie plutôt un wrapper autour d'une opération en cours. Ce wrapper est généralement un Task, mais sur Windows RT, il peut l'être IAsyncInfo. Suivez votre instinct et rappelez-vous que si un utilisateur de votre code voit la Asyncfonction, il saura que l'invocation de cette méthode est découplée du résultat de cette méthode et qu'il doit agir en conséquence.

Notez qu'il existe des méthodes telles que Task.Delayet Task.WhenAllqui retournent Tasket qui n'ont pas le Asyncsuffixe.

Notez également qu'il existe des async voidméthodes qui représentent le feu et oublient la méthode asynchrone et vous devriez mieux être conscient que la méthode est construite de cette manière.

Je dirais qu'il devrait utiliser le suffixe Async s'il renvoie une tâche, que la méthode soit déclarée avec le asyncmodificateur ou non.

La raison en est que le nom est déclaré dans l'interface. L'interface déclare le type de retour qui est un Task. Ensuite, il y a deux implémentations de cette interface, une implémentation l'implémente en utilisant le asyncmodificateur, l'autre non.

public interface IFoo
{
    Task FooAsync();
}

public class FooA : IFoo
{
    public Task FooAsync() { /* ... */ }
}

public class FooB : IFoo
{
    public async Task FooAsync() { /* ... */ }
}

Dans la programmation asynchrone avec async et await (C #) , Microsoft propose les conseils suivants:

Convention de dénomination

Par convention, vous ajoutez «Async» aux noms des méthodes qui ont un modificateur async .

Vous pouvez ignorer la convention selon laquelle un événement, une classe de base ou un contrat d'interface suggère un nom différent. Par exemple, vous ne devez pas renommer les gestionnaires d'événements courants, tels que Button1_Click.

Je trouve cette orientation incomplète et insatisfaisante. Cela signifie-t-il qu'en l'absence du asyncmodificateur, cette méthode devrait être nommée à la Connectplace de ConnectAsync?

public Task<bool> ConnectAsync()
{
    return ConnectAsyncInternal();
}

Je ne pense pas. Comme indiqué dans la réponse concise par @Servy et plus réponse détaillée par @Luke Puplett , je crois qu'il est approprié et bien prévu que cette méthode devrait être nommé ConnectAsync(car il renvoie un awaitable). À l'appui de cela, @John Skeet dans cette réponse à une autre question ajoute Asyncau nom de la méthode indépendamment de la présence du asyncmodificateur.

Enfin, sur une autre question , considérez ce commentaire de @Damien_The_Unbeliever :

async/awaitsont les détails de mise en œuvre de vos méthodes. Peu importe que votre méthode soit déclarée async Task Method()ou juste Task Method(), en ce qui concerne vos appelants . (En fait, vous êtes libre de changer entre ces deux à un moment ultérieur sans que cela soit considéré comme un changement radical.)

De là, j'en déduis que c'est la nature asynchrone de la méthode qui dicte comment elle doit être nommée. L'utilisateur de la méthode ne saura même pas si le asyncmodificateur est utilisé dans son implémentation (sans le code source C # ou CIL).