C# method declaration - IEnumerable vs List [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-5
down vote
favorite
Is it really a best practice to use IEnumerable<T> in method declaration, instead of List<T>?
Method1(IEnumerable<T> collections);
Method2(List<T> collections);
c#
asked Feb 4 at 17:49
codeninja.sj
911
closed as off-topic by Malachi♦, t3chb0t, Mast, ÀάνÄα ῥεῖ, Sam Onela Feb 4 at 18:48
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Mast, Sam Onela
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." – Malachi, t3chb0t, ÀάνÄα ῥεῖ
add a comment |Â
up vote
-5
down vote
favorite
Is it really a best practice to use IEnumerable<T> in method declaration, instead of List<T>?
Method1(IEnumerable<T> collections);
Method2(List<T> collections);
c#
asked Feb 4 at 17:49
codeninja.sj
911
closed as off-topic by Malachi♦, t3chb0t, Mast, ÀάνÄα ῥεῖ, Sam Onela Feb 4 at 18:48
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Mast, Sam Onela
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." – Malachi, t3chb0t, ÀάνÄα ῥεῖ
add a comment |Â
up vote
-5
down vote
favorite
up vote
-5
down vote
favorite
Is it really a best practice to use IEnumerable<T> in method declaration, instead of List<T>?
Method1(IEnumerable<T> collections);
Method2(List<T> collections);
c#
asked Feb 4 at 17:49
codeninja.sj
911
Is it really a best practice to use IEnumerable<T> in method declaration, instead of List<T>?
Method1(IEnumerable<T> collections);
Method2(List<T> collections);
c#
asked Feb 4 at 17:49
codeninja.sj
911
asked Feb 4 at 17:49
codeninja.sj
911
asked Feb 4 at 17:49
codeninja.sj
911
asked Feb 4 at 17:49
codeninja.sj
911
911
closed as off-topic by Malachi♦, t3chb0t, Mast, ÀάνÄα ῥεῖ, Sam Onela Feb 4 at 18:48
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Mast, Sam Onela
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." – Malachi, t3chb0t, ÀάνÄα ῥεῖ
closed as off-topic by Malachi♦, t3chb0t, Mast, ÀάνÄα ῥεῖ, Sam Onela Feb 4 at 18:48
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Mast, Sam Onela
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." – Malachi, t3chb0t, ÀάνÄα ῥεῖ
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
That all depends on what Method1 is doing. If you have this signature:
void Method1(IEnumerable<T> items);
Then when I use your method, you are telling me (through the signature) that you will not be adding to the items but simply iterating over them. In other words, you will be using only the methods of IEnumerable.
However, if the signature is like this:
void Method1(List<T> items);
Then it tells me that you may add, remove items from the list I provide to your method (or any other method exposed by List<T>). Therefore, if I do not want you to add/remove items to my list, I will create a copy of my list and give you the copy. That way my list is safe from you.
Therefore, it all depends on what the method is doing or needs to do. A good practice is to only ask for the minimum--for the most general interface. If all you need to do is to loop through the items, then do not ask for List<T> but ask for IEnumerable<T>.
answered Feb 4 at 18:19
CodingYoshi
54416
IList<T>, however, is pretty well always preferable toList<T>. Furthermore, if you need an ordered list but don't need to modify it, use anIReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.
– VisualMelon
Feb 4 at 18:23
4
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass meIEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.
– CodingYoshi
Feb 5 at 12:18
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
That all depends on what Method1 is doing. If you have this signature:
void Method1(IEnumerable<T> items);
Then when I use your method, you are telling me (through the signature) that you will not be adding to the items but simply iterating over them. In other words, you will be using only the methods of IEnumerable.
However, if the signature is like this:
void Method1(List<T> items);
Then it tells me that you may add, remove items from the list I provide to your method (or any other method exposed by List<T>). Therefore, if I do not want you to add/remove items to my list, I will create a copy of my list and give you the copy. That way my list is safe from you.
Therefore, it all depends on what the method is doing or needs to do. A good practice is to only ask for the minimum--for the most general interface. If all you need to do is to loop through the items, then do not ask for List<T> but ask for IEnumerable<T>.
answered Feb 4 at 18:19
CodingYoshi
54416
IList<T>, however, is pretty well always preferable toList<T>. Furthermore, if you need an ordered list but don't need to modify it, use anIReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.
– VisualMelon
Feb 4 at 18:23
4
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass meIEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.
– CodingYoshi
Feb 5 at 12:18
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
 |Â
show 1 more comment
up vote
2
down vote
That all depends on what Method1 is doing. If you have this signature:
void Method1(IEnumerable<T> items);
Then when I use your method, you are telling me (through the signature) that you will not be adding to the items but simply iterating over them. In other words, you will be using only the methods of IEnumerable.
However, if the signature is like this:
void Method1(List<T> items);
Then it tells me that you may add, remove items from the list I provide to your method (or any other method exposed by List<T>). Therefore, if I do not want you to add/remove items to my list, I will create a copy of my list and give you the copy. That way my list is safe from you.
Therefore, it all depends on what the method is doing or needs to do. A good practice is to only ask for the minimum--for the most general interface. If all you need to do is to loop through the items, then do not ask for List<T> but ask for IEnumerable<T>.
answered Feb 4 at 18:19
CodingYoshi
54416
IList<T>, however, is pretty well always preferable toList<T>. Furthermore, if you need an ordered list but don't need to modify it, use anIReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.
– VisualMelon
Feb 4 at 18:23
4
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass meIEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.
– CodingYoshi
Feb 5 at 12:18
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
 |Â
show 1 more comment
up vote
2
down vote
up vote
2
down vote
That all depends on what Method1 is doing. If you have this signature:
void Method1(IEnumerable<T> items);
Then when I use your method, you are telling me (through the signature) that you will not be adding to the items but simply iterating over them. In other words, you will be using only the methods of IEnumerable.
However, if the signature is like this:
void Method1(List<T> items);
Then it tells me that you may add, remove items from the list I provide to your method (or any other method exposed by List<T>). Therefore, if I do not want you to add/remove items to my list, I will create a copy of my list and give you the copy. That way my list is safe from you.
Therefore, it all depends on what the method is doing or needs to do. A good practice is to only ask for the minimum--for the most general interface. If all you need to do is to loop through the items, then do not ask for List<T> but ask for IEnumerable<T>.
answered Feb 4 at 18:19
CodingYoshi
54416
That all depends on what Method1 is doing. If you have this signature:
void Method1(IEnumerable<T> items);
Then when I use your method, you are telling me (through the signature) that you will not be adding to the items but simply iterating over them. In other words, you will be using only the methods of IEnumerable.
However, if the signature is like this:
void Method1(List<T> items);
Then it tells me that you may add, remove items from the list I provide to your method (or any other method exposed by List<T>). Therefore, if I do not want you to add/remove items to my list, I will create a copy of my list and give you the copy. That way my list is safe from you.
Therefore, it all depends on what the method is doing or needs to do. A good practice is to only ask for the minimum--for the most general interface. If all you need to do is to loop through the items, then do not ask for List<T> but ask for IEnumerable<T>.
answered Feb 4 at 18:19
CodingYoshi
54416
answered Feb 4 at 18:19
CodingYoshi
54416
answered Feb 4 at 18:19
CodingYoshi
54416
answered Feb 4 at 18:19
CodingYoshi
54416
54416
IList<T>, however, is pretty well always preferable toList<T>. Furthermore, if you need an ordered list but don't need to modify it, use anIReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.
– VisualMelon
Feb 4 at 18:23
4
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass meIEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.
– CodingYoshi
Feb 5 at 12:18
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
 |Â
show 1 more comment
IList<T>, however, is pretty well always preferable toList<T>. Furthermore, if you need an ordered list but don't need to modify it, use anIReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.
– VisualMelon
Feb 4 at 18:23
4
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass meIEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.
– CodingYoshi
Feb 5 at 12:18
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
IList<T>, however, is pretty well always preferable to List<T>. Furthermore, if you need an ordered list but don't need to modify it, use an IReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.– VisualMelon
Feb 4 at 18:23
IList<T>, however, is pretty well always preferable to List<T>. Furthermore, if you need an ordered list but don't need to modify it, use an IReadOnlyList<T>. A less demanding type also gives the caller more options: they can pass a HashSet as an IEnumerable, but not as an IList.– VisualMelon
Feb 4 at 18:23
4
4
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
It's not only about whether someone is going to add something to the collection or not but rather whether the collection is already materialized and I can safely itereate it multiple times or do I have to materialize it myself first. Btw. this question should not have been answered in the first place as it's clearly off-topic for CR.
– t3chb0t
Feb 4 at 18:28
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass me
IEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.– CodingYoshi
Feb 5 at 12:18
@t3chb0t Yes you are right, I should not have answered it but I thought it was on software engineering. As to it being materialized, that is not the receiver's responsibility but the sender's (caller's). If you pass me
IEnumerable<T>, and it is not materialized, that is too bad. In other words, to fix that you would not necessarily go into the method receiving it and ensure it only traverses once, but fix it in the caller.– CodingYoshi
Feb 5 at 12:18
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
I cannot agree. The method requesting parameters must know wheter it's ok to pass it some collection or a materialized one. If I know that I'll be using it a lot I request it to already be populated. It's not a caller decistion but the callee's.
– t3chb0t
Feb 5 at 12:23
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
t3chb0t But that would be sort of a "secret" and it would need to be documented. And doing that in a public API would be totally insane. It is better to code against interfaces than to code against "secrets" buried in the docs.
– CodingYoshi
Feb 5 at 12:29
 |Â
show 1 more comment