Task with Async signature vs no-signature
I have little mess up things with tasks. So please explain me which is the main difference between a Task with signature vs no-signature.
Example
async Task myTaskAsync();
vs
async Task myTask();
Is there any difference if i will not include Async in my end of fuction?
c# naming-conventions
edited Nov 15 '18 at 8:30
JohnB
1,89011218
asked Nov 15 '18 at 8:25
dddddd
357
|
show 4 more comments
I have little mess up things with tasks. So please explain me which is the main difference between a Task with signature vs no-signature.
Example
async Task myTaskAsync();
vs
async Task myTask();
Is there any difference if i will not include Async in my end of fuction?
c# naming-conventions
edited Nov 15 '18 at 8:30
JohnB
1,89011218
asked Nov 15 '18 at 8:25
dddddd
357
No, it is just a naming convention. You can name it as you wish
– Tomas Chabada
Nov 15 '18 at 8:27
1
No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL).
– Fildor
Nov 15 '18 at 8:27
Thank you for the asnwer. One last question, is it better to use async task instead async void?
– ddd
Nov 15 '18 at 8:31
async void is for EventHandlers. blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types"
– Fildor
Nov 15 '18 at 8:31
2
The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately.
– Casperonian
Nov 15 '18 at 8:31
|
show 4 more comments
I have little mess up things with tasks. So please explain me which is the main difference between a Task with signature vs no-signature.
Example
async Task myTaskAsync();
vs
async Task myTask();
Is there any difference if i will not include Async in my end of fuction?
c# naming-conventions
edited Nov 15 '18 at 8:30
JohnB
1,89011218
asked Nov 15 '18 at 8:25
dddddd
357
I have little mess up things with tasks. So please explain me which is the main difference between a Task with signature vs no-signature.
Example
async Task myTaskAsync();
vs
async Task myTask();
Is there any difference if i will not include Async in my end of fuction?
c# naming-conventions
c# naming-conventions
edited Nov 15 '18 at 8:30
JohnB
1,89011218
asked Nov 15 '18 at 8:25
dddddd
357
edited Nov 15 '18 at 8:30
JohnB
1,89011218
asked Nov 15 '18 at 8:25
dddddd
357
edited Nov 15 '18 at 8:30
JohnB
1,89011218
edited Nov 15 '18 at 8:30
JohnB
1,89011218
edited Nov 15 '18 at 8:30
JohnB
1,89011218
1,89011218
asked Nov 15 '18 at 8:25
dddddd
357
asked Nov 15 '18 at 8:25
dddddd
357
asked Nov 15 '18 at 8:25
dddddd
357
357
No, it is just a naming convention. You can name it as you wish
– Tomas Chabada
Nov 15 '18 at 8:27
1
No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL).
– Fildor
Nov 15 '18 at 8:27
Thank you for the asnwer. One last question, is it better to use async task instead async void?
– ddd
Nov 15 '18 at 8:31
async void is for EventHandlers. blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types"
– Fildor
Nov 15 '18 at 8:31
2
The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately.
– Casperonian
Nov 15 '18 at 8:31
|
show 4 more comments
No, it is just a naming convention. You can name it as you wish
– Tomas Chabada
Nov 15 '18 at 8:27
1
No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL).
– Fildor
Nov 15 '18 at 8:27
Thank you for the asnwer. One last question, is it better to use async task instead async void?
– ddd
Nov 15 '18 at 8:31
async void is for EventHandlers. blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types"
– Fildor
Nov 15 '18 at 8:31
2
The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately.
– Casperonian
Nov 15 '18 at 8:31
No, it is just a naming convention. You can name it as you wish
– Tomas Chabada
Nov 15 '18 at 8:27
No, it is just a naming convention. You can name it as you wish
– Tomas Chabada
Nov 15 '18 at 8:27
1
1
No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL).
– Fildor
Nov 15 '18 at 8:27
No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL).
– Fildor
Nov 15 '18 at 8:27
Thank you for the asnwer. One last question, is it better to use async task instead async void?
– ddd
Nov 15 '18 at 8:31
Thank you for the asnwer. One last question, is it better to use async task instead async void?
– ddd
Nov 15 '18 at 8:31
async void is for EventHandlers. blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types"
– Fildor
Nov 15 '18 at 8:31
async void is for EventHandlers. blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types"
– Fildor
Nov 15 '18 at 8:31
2
2
The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately.
– Casperonian
Nov 15 '18 at 8:31
The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately.
– Casperonian
Nov 15 '18 at 8:31
|
show 4 more comments
2 Answers
2
active
oldest
votes
It does not matter regarding the behavior of the function if you add the "Async" suffix or not.
It does matter regarding the perception of your API by clients.
This naming convention is broadly adopted, so you do yourself and others a favor using it.
BTW:
If that API in question already contains legacy async functions (non-TAP) that are named "xxxAsync", then it is recommended to use "xxxTaskAsync" instead.
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
add a comment |
Yes, it matters when you care about your code design, for example:
public interface IMyService
{
Task<int> GetWeightAsync();
int GetWeight();
}
In this case you support both: async and non-async version for users of this interface, so they can decide which path they want to choose.
C# is designed polimorphic, but in case of async, it is just way to fake it. The compiler will still complain if signature will be same except return value, so people decided to add suffix 'Async' at the end.
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
1
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53315136%2ftask-with-async-signature-vs-no-signature%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It does not matter regarding the behavior of the function if you add the "Async" suffix or not.
It does matter regarding the perception of your API by clients.
This naming convention is broadly adopted, so you do yourself and others a favor using it.
BTW:
If that API in question already contains legacy async functions (non-TAP) that are named "xxxAsync", then it is recommended to use "xxxTaskAsync" instead.
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
add a comment |
It does not matter regarding the behavior of the function if you add the "Async" suffix or not.
It does matter regarding the perception of your API by clients.
This naming convention is broadly adopted, so you do yourself and others a favor using it.
BTW:
If that API in question already contains legacy async functions (non-TAP) that are named "xxxAsync", then it is recommended to use "xxxTaskAsync" instead.
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
add a comment |
It does not matter regarding the behavior of the function if you add the "Async" suffix or not.
It does matter regarding the perception of your API by clients.
This naming convention is broadly adopted, so you do yourself and others a favor using it.
BTW:
If that API in question already contains legacy async functions (non-TAP) that are named "xxxAsync", then it is recommended to use "xxxTaskAsync" instead.
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
It does not matter regarding the behavior of the function if you add the "Async" suffix or not.
It does matter regarding the perception of your API by clients.
This naming convention is broadly adopted, so you do yourself and others a favor using it.
BTW:
If that API in question already contains legacy async functions (non-TAP) that are named "xxxAsync", then it is recommended to use "xxxTaskAsync" instead.
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
edited Nov 15 '18 at 8:58
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
answered Nov 15 '18 at 8:53
FildorFildor
7,17732246
7,17732246
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
add a comment |
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
A similar question has been answered here: stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself.
– Fildor
Nov 15 '18 at 8:57
add a comment |
Yes, it matters when you care about your code design, for example:
public interface IMyService
{
Task<int> GetWeightAsync();
int GetWeight();
}
In this case you support both: async and non-async version for users of this interface, so they can decide which path they want to choose.
C# is designed polimorphic, but in case of async, it is just way to fake it. The compiler will still complain if signature will be same except return value, so people decided to add suffix 'Async' at the end.
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
1
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
add a comment |
Yes, it matters when you care about your code design, for example:
public interface IMyService
{
Task<int> GetWeightAsync();
int GetWeight();
}
In this case you support both: async and non-async version for users of this interface, so they can decide which path they want to choose.
C# is designed polimorphic, but in case of async, it is just way to fake it. The compiler will still complain if signature will be same except return value, so people decided to add suffix 'Async' at the end.
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
1
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
add a comment |
Yes, it matters when you care about your code design, for example:
public interface IMyService
{
Task<int> GetWeightAsync();
int GetWeight();
}
In this case you support both: async and non-async version for users of this interface, so they can decide which path they want to choose.
C# is designed polimorphic, but in case of async, it is just way to fake it. The compiler will still complain if signature will be same except return value, so people decided to add suffix 'Async' at the end.
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
Yes, it matters when you care about your code design, for example:
public interface IMyService
{
Task<int> GetWeightAsync();
int GetWeight();
}
In this case you support both: async and non-async version for users of this interface, so they can decide which path they want to choose.
C# is designed polimorphic, but in case of async, it is just way to fake it. The compiler will still complain if signature will be same except return value, so people decided to add suffix 'Async' at the end.
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
edited Nov 15 '18 at 8:32
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
answered Nov 15 '18 at 8:28
eocroneocron
3,807834
3,807834
1
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
add a comment |
1
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
1
1
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
It is still just a convention. Naming it "Herbert()" won't change anything (but the name).
– Fildor
Nov 15 '18 at 8:30
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage).
– eocron
Nov 15 '18 at 8:34
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
But it will not behave differently. That's what I am saying.
– Fildor
Nov 15 '18 at 8:36
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it.
– eocron
Nov 15 '18 at 8:41
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53315136%2ftask-with-async-signature-vs-no-signature%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
No, it is just a naming convention. You can name it as you wish
– Tomas Chabada
Nov 15 '18 at 8:27
1
No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL).
– Fildor
Nov 15 '18 at 8:27
Thank you for the asnwer. One last question, is it better to use async task instead async void?
– ddd
Nov 15 '18 at 8:31
async void is for EventHandlers. blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types"
– Fildor
Nov 15 '18 at 8:31
2
The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately.
– Casperonian
Nov 15 '18 at 8:31