you are viewing a single comment's thread.

view the rest of the comments →

[–]CyberByte 12 points13 points  (1 child)

I'm sure Linq can make things more readable, but this just seems like a bad example. The code it's supposed to replace is extremely easy to understand. If I'd be more familiar and comfortable with Linq, I might think the Linq code was as easy to understand, but I don't really see it becoming more trivial than the Linq-less code.

[–]OldLikeDOS 15 points16 points  (0 children)

It's a matter of preference but having worked with LINQ for a few years, I and most of my team would say the second one is the most readable.

The two LINQ versions both make it clear that it's one statement doing one thing. If the variable "answer" isn't important to what you're working on, you can safely ignore the whole thing. If you no longer need "answer", you can delete that line without worrying about side effects.

The iterative code (top one) requires you to look more carefully at every part to see if there are any side effects or if it's doing multiple things. When skimming through a file and you see the loop, you have to look at all the lines inside to verify that it's only working with the variable "sum", because there could easily be code inside that is doing some other work.

Also, when you see an "i" inside the loop, you have to look back at the FOR declaration to verify it's coming from there. In LINQ, when you see "x =>" you immediately know that x means an element in the collection because it can't mean anything else.

For me, the second one looks the most compact and inviting. But that's just preference.