What is more readable?

Question

Do I have these two codes, one of which is more readable?

• Eogeasp

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

• LINQ

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

Answer 1

If the team working on the code knows what the Linq version does and knows its internal work, then it is more readable.

Answer 2

Use what you prefer, but hide it in the method:

 return risks.SumTechnicalPremium(); 

Answer 3

None. The first one is more detailed and is likely to be understood by everyone. The second is more concise and easy to understand for everyone who even has a passing knowledge of linq.

I would say that you can use your choice in the environment in which you are.

Answer 4

For those who can read LINQ, LINQ.

For those who need to interpret the code step by step (using intellisense / documentation is shorter.

Answer 5

Go with linq. If you think this requires explanation, this will follow a single line. As people are more used to linq, the need for comments will disappear.

Answer 6

LINQ code is very readable and self-documenting.

Answer 7

The first option is read to a wider circle of people. The second option has an “entry barrier” in the sense that the reader can or can know and understand LINQ. This is more eloquent, and therefore it might be better if your audience completes this entry barrier.

Answer 8

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

Answer 9

I would say the first one since I don't know linq. In the danger of documentation, I would take advantage of this with a brief description of what is happening. Or just say this linq for people who may not have a clue.

Answer 10

If you provide a comment explaining its purpose, I would go for the Linq option.

Answer 11

First, if you do not know Linq. Any developer can read and understand the first.

Answer 12

There is no problem of readability. Press Sum and press F1.

Linq for victory.

Answer 13

Every language has conventions for a better way to encode such things, so most readers for people who regularly use the language aren't universal. For Java or a regular C # programmer, the first option is more readable. For someone used for LINQ or functional programming, the second is more readable.

Answer 14

I don't know C #, but the second option looks a lot cleaner for me, and I could understand what it was doing (well, with some guesswork and cross-checking with the first version). Probably due to some kind of functional background. But in the first you need to look for a technical Premium in 4 (!) Places. The second is much shorter and clearer if you just read the code.

Answer 15

or

decimal technicalPremium = 0;

foreach (risk at risk) technicalPremium = technicalPremium + risk.TechnicalPremium;

return technicalPremium;

Answer 16

I see that people say that they like the first "if you don't know Linq." Yes, and the first one is unreadable if you don't know C #. This is not a question of “what is more readable,” but “what language features are more convenient for us to use?”

Start by talking with your team about the parts of the language / framework / toolkit that everyone hates, and declare them out of bounds. Everything else is considered part of the standard vocabulary, and everyone is expected to speak fluently. This list should go into your coding standards standard, next to “ never create mutable value types ” and “ don't worry about trivial properties for non-public participants .

As long as Linq is not on your exception list, the second example is much more readable than the first. What for? Because it declares the intention of the code, and not just presents a mechanism for decrypting the reader.

Answer 17

If your goal is to make it more readable for "anyone" that may follow you, then use foreach. I interpret "more readable" to understand that anyone who has experience in the basics of the language should be able to understand. For someone unfamiliar with linq and using VS2005 or earlier, the linq syntax will be confused.

Answer 18

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

Answer 19

I agree with those who say the second will be easily understood as Linq is becoming more widely accepted. This is certainly more eloquent.

However, I'm a little concerned about the ease of debugging. It seems a lot easier to go through the code in foreach to see what exactly it does in each pass.

Answer 20

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

For me, the second example is more intuitive based on the context (i.e. you take an array (or some other type of collection) and execute a method called Sum for each element of this array). The only place where the second example may become less clear is the actual lambda expression, especially for those who have no previous experience with lambdas or alraedy, there is a background in functional programming.

I think that as lambdas become more common in .NET programming, this will become less of a problem. Be that as it may, I think there is a very small learning curve to understand the basics of using lambda expressions in .NET.

Answer 21

The second, of course. Having such a large block of code to do something as simple as summing is simply not necessary. I also don’t know what LINQ is, but it is perfectly readable for me.