Empty lines in functions / methods

Question

At our Xmas party, we had an almost physical battle over one problem: whether or not to allow empty lines in a function / method in our code (c / C ++ / C #). This is just one empty line, for example, present the code as:

private void LoadData() { if (!loaded) return; DataStore coll; SqlData s = new SqlData(); if (!s.CallStoredProcedureToStore(out coll, "xy.usp_zzz",...)) return; dataViewXy.BeginUpdate(); dataViewXy.Items.Clear(); for(int i = 0; i < coll.RowCount; i++) { dataViewXy.Items.Add(coll[i]["ID"]); } dataViewXy.EndUpdate(); } 

this is a meaningless mix, just to illustrate the situation - the first block of data loads of functions, the second fills some kind of data control, and an empty line separates them.

You should also write a comment before each "block", but the important thing is that for the guys there will be an empty line before this comment, but not against the guys.

For : allows the programmer to logically separate pieces of the function in order to improve readability in the form of some visual signals for the eyes following

Cons : reduces readability, and the programmer should use a comment to separate fragments of a function.

My personal opinion is to have empty lines in functions, because without them, long code snippets look like an endless stream of lines to me without any hints about where to find what I'm looking for)

Answer 1

It will be a terrific duel to watch. Just like the final scene in The Good, The Bad, and the Ugly , but instead of the space bar of the method instead of gold.

Honestly, this should not even matter if you do not need to constantly ponder someone’s code on your team quite often. Personally, I am all for spaces, as it gives a logical grouping. But this may not be the case for someone else. Damn, even I can change the way I group things over time. Grouped elements that previously made sense could no longer be.

No matter how we group the elements, I think grouping is very important. We can argue about why empty lines are not needed, but the fact is that the brain can only process a limited amount of information at a time. Therefore, if I can understand a function consisting of three subgroups, for example, instead of ten operators, this is of great importance. And comment grouping is subjective to your IDE. Most IDEs color them easily than the rest of the code, which gives a sense of separation, but this becomes specific to the IDE.

So, to talk about the essence, all about the grouping. If the class gets too big, we must break it for understanding and service. Similarly, if consecutive lines of code inside a method are too complicated, it must be split into several methods or logically separated by an empty blank line.

Also, if the argument is worthless, introduce some random things, such as how these blank lines relate to the Buddhist concept of non-existence bla bla ..

Answer 2

I think the empty line in the method body is the smell of code. Read this blog post on this topic: An empty line is the smell of code . In short, empty lines in the body of a method are bad practice because the method should not contain "parts". A method should always do one thing, and its functional decomposition should be performed using language constructs (for example, new methods) and never empty lines.

Answer 3

"One size fits all", such rules do not work.

There are valid arguments for and against each point of view. I could contrast your argument with "long lines of code" by saying that such functions should be broken down into subroutines.

However, this does not apply to the point.

Saying “SHOULD” insert empty lines is just as pointless as saying that you CANNOT insert empty lines.

The BW law in these situations is “use what works for you”

If this needs to be resolved, vote and agree so that everyone agrees to vote before the vote (even if you lose).

What are my two cents.

PS My personal opinion is for empty lines.

Answer 4

Definitely, although this issue may be subjective.

In addition, I learned how to split a method if it gets too big, and can “compress” it by deleting the inbox.

Answer 5

Physical battle? At the christmas party? Sounds like a fun place.

I am also a proponent of spaces when it improves readability. This is part of the reason I also advocate aligning curly braces: extra spaces visually render a block of code.

Most comments are erratic and do not help to read. If they do not add information to help understand the code, they only get in the way.

It seems like I would fight the crowd of "no whitespace / add comments".

Answer 6

My rule is to place all variable declarations at the beginning of the function, followed by processing, and then the return statement (if any), each of which is separated by blank lines.

  int DoSomething (string robot)
 {
     int result = 0;

     if (robot == "robot")
         result = 42;

     return result;
 }

If this is a moderately complex method with logically distinct blocks of code that do not require encapsulation in their own methods, I also separate them with spaces. Everything that can be equated to a “paragraph” of code is separated by an empty line.

I leave most of the comments in the /// comment blocks at the top of the method.

Answer 7

I'm all for spaces - this is a small amount of memory usage, which significantly improves the readability of the code, reducing the program to logical steps. This is not a substitute for good comments, however . My comment rule: “Don't try to do something annoying in other people's code (which usually doesn't comment - just“ // do X and Y if Z says it's necessary ”is a good level of detail for an individual comment, which I I think)

We have plenty of storage space and good-sized monitors, so why not use it to make it easier?

Huge chunks of spaces can push the code from the screen, but this prevents the ability to look at the code and get a good overview, so it’s better not to overdo it.

Like everything in programming, it depends on the particular case, personal preferences and a hint of moderation.