What is more readable?

Question

I have these two pieces of code, wich one is more readable?

1. foreach

   decimal technicalPremium = 0;
   foreach (Risk risk in risks)
   {
        technicalPremium = technicalPremium + risk.TechnicalPremium;
   }
   return technicalPremium;
   

2. linq

   return risks.Sum(risk => risk.TechnicalPremium);
   

Answer 1

I vote for linq option.

Edit: However it does not matter. As cristianlibardo said, wrap it to the well named function.

Answer 2

If the team that works on the code knows what the Linq version does and knows its inner workings, then it is more readable.

Answer 3

I think the second option is better in that it should be more efficient. It is, however, less obvious what is happening (at least to me).

Answer 4

For someone who can read LINQ, the LINQ one.

For someone who has to interpret the code step by step (by using intellisense/documentation the shorter one.

Answer 5

The LINQ code is both very readable and self-documenting.

Answer 6

Neither. The first one is more verbose and likely to be understood by everyone. The second one is more concise and easily understood by everyone with even a passing knowledge of linq.

I'd say you can base your choice on the environment you are in.

Answer 7

Go with linq. If you think it needs explanation, a one line comment will take care of that. As people get more used to linq, the need for comments will go away.

Answer 8

I'd say the first since I don't know linq. At risk of over documenting I'd use that one with a short description of what is going on. Or just say it's linq for people who may have no idea.

Answer 9

The first option is more readable to a wider range of people. The second option has an 'entry barrier' in that the reader might or might know and understand LINQ. It is more succinct, and might be therefore better if your audience is over that entry barrier.

Answer 10

If you provide a comment explaining it's purpose, then I'd go for the Linq option.

Answer 11

The first if you have no knowledge of Linq. Anyone developer can read and understand the first one.

Answer 12

There's no readability problem here. Click on Sum and hit F1.

Linq for the win.

Answer 13

Each language has conventions for the best way to code such things, so what's most readable to people who regularly use that language isn't universal. For a Java or normal C# programmer, the first option is more readable. For somebody used to LINQ or functional programming, the second is more readable.

Answer 14

Use whichever you prefer but hide it in a method:

return risks.SumTechnicalPremium();

Answer 15

I don't know c# but the second alternative looks much cleaner to me and I could understand what it does (ok, with some guessing and cross-checking with the first version). Probabably because of some functional background. But in the first you have to look for technicalPremium in 4(!) places. The second one is much shorter and easier to understand if you are just reading over the code.

Answer 16

or

decimal technicalPremium = 0;

foreach (Risk risk in risks) technicalPremium = technicalPremium + risk.TechnicalPremium;

return technicalPremium;

Answer 17

I see people saying they like the first one "if you don't know Linq". Yeah, and the first one is unreadable if you don't know C#. This isn't a question of "which is more readable", but "which language features are we comfortable using?"

Start by having a conversation with your team about the parts of the language/framework/toolset that everyone hates, and declare them off limits. Everything else is considered part of the standard vocabulary, and everyone is expected to be fluent. This list should go in your coding standards doc, right next to "never make mutable value types" and "don't bother with trivial properties for non-public members".

As long as Linq is not on your "exclude" list, the second example is far more readable than the first. Why? Because it declares intent of the code, instead of merely presenting the mechanism for the reader to decipher.

Answer 18

If your goal is to make it more readable for "anyone" that might come after you, then use the foreach. I interpret "more readable" to mean anyone with experience in the basics of the language should be able to grasp. For someone unfamiliar with linq and still using VS2005 or earlier, the linq syntax would be confusing.

Answer 19

I would say that the first piece of code is definitely more readable, and it would be even more readable if you renamed at least the variable risk so that it had a different name from the class. It would probably also be better if you renamed the array risks.

Answer 20

I agree with those who say the second will be easily understood as Linq becomes more widely adopted. It is certainly more succinct.

However, I have some concern over ease of debugging. It seems much easier to step through the code in the foreach, to see exactly what it is doing in each pass.

Answer 21

I think it depends on what you mean by "readable". The first example clearly indicates the program logic and should be understandable by anyone with a programming background.

To me, the second example is more intuitive based on the context (i.e., you are taking an array (or some other collection type) and executing a method named Sum on each element of that array). The only place the second example can become less clear is in the actual lambda expression itself especially for someone who hasn't had experience with lambdas or alraedy have a background in functional programming.

I think as lambdas become more prevalent in .NET programming this will become less of an issue. As it stands, I think there is a very small learning curve to understanding the basics of how to use lambda expressions in .NET.

Answer 22

The second one, definitely. Having such a large block of code for doing something as simple as summing is just unnecessary. I also don't know what LINQ is, but it's perfectly readable to me.