• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Which is more readable?

Bulldog13

Golden Member
Pedantic, I know, but which do you think is more readable...and why?

Code:
this.SmartFiles.ForEach(t => ExtractInfoFromFilePayload(t));
            
this.SmartFiles.ForEach<FileSortCell>(ExtractInfoFromFilePayload);

Kind of a silly question, but I figured I would ask the board 🙂
 
Neither is significantly easier than the other. They also don't appear equivalent, since I can't see what happened to the instance being yielded from the enumerator in the second example.
 
Pedantic, I know, but which do you think is more readable...and why?

Code:
this.SmartFiles.ForEach(t => ExtractInfoFromFilePayload(t));
            
this.SmartFiles.ForEach<FileSortCell>(ExtractInfoFromFilePayload);

Kind of a silly question, but I figured I would ask the board 🙂

I understood the first one. The second one looks like gibberish. So for me, the 1st one is more readable.
 
the second is easier to read IMO.

reminds me of using comparators on a list of info
 
Last edited:
Also, the two options have a kind of different feeling :

- the first would enumerate all items in this.SmartFiles and call ExtractInfoFromFilePayload on them
- whereas the second one will enumerate only the FileSortCell items in this.SmartFiles and call ExtractInfoFromFilePayload on them

This distinction seems purely academic if your SmartFiles is an IEnumerable<FileSortCell>, but feels different. At the least, the first option would not compile if SmartFiles was not an IEnumerable<FileSortCell> (and ExtractInfoFromFilePayload only takes a FileSortCell of course), and I think the second would.

EDIT : removed code tags, because they can't be used inline.
 
Last edited:
I'd say they're both unreadable. Probably because I lack context of what this is, what the other types are, etc.
 
I can decipher both of them just fine. If I must choose, I'd go with the second, just because it points to the type inline.


I'd say they're both unreadable. Probably because I lack context of what this is, what the other types are, etc.

C# Anonymous Delegates and Lambdas
 
About the same for me. The one I would choose would depend on what each of the objects are and who I expect to use the code.
 
I can decipher both of them just fine. If I must choose, I'd go with the second, just because it points to the type inline.




C# Anonymous Delegates and Lambdas

I still don't get what's going on in the second one. A lambda would accept the yielded instance as an argument, i.e.,

this.SmartFiles.ForEach<FileSortCell>(t => ExtractInfoFromFilePayload(t));
 
I still don't get what's going on in the second one. A lambda would accept the yielded instance as an argument, i.e.,

this.SmartFiles.ForEach<FileSortCell>(t => ExtractInfoFromFilePayload(t));

Well, one way to think about the second call is to go back in time before lambdas existed. The ForEach<T>() method accepts an Action<T> delegate (whose signature is to accept a single parameter and not return a value).

When I look at the original method call (second call in the original post), I read it as: SmartFiles is an IList containing elements of type FileSortCell. I want to perform some action on every item in the list, so I am going to utilize ExtractInfoFromFilePayload method whose signature matches that of an Action<T> delegate (hence, the call to ForEach inline).

In a way, you can think about the first method call as being archaic and redundant... it is valid because lambdas and LINQ made it valid later on, not because it was meant to be primary functionality. I guess this last point may come across as being confusing... someone else may be able to explain it better.
 
Last edited:
Well, one way to think about the second call is to go back in time before lambdas existed. The ForEach<T>() method accepts an Action<T> delegate (whose signature is to accept a single parameter and not return a value).

When I look at the original method call (second call in the original post), I read it as: SmartFiles is an IList containing elements of type FileSortCell. I want to perform some action on every item in the list, so I am going to utilize ExtractInfoFromFilePayload method whose signature matches that of an Action<T> delegate (hence, the call to ForEach inline).

In a way, you can think about the first method call as being archaic and redundant... it is valid because lambdas and LINQ made it valid later on, not because it was meant to be primary functionality. I guess this last point may come across as being confusing... someone else may be able to explain it better.

Ah, right, yep. I see what you're saying.
 
Back
Top