empty lines in functions/methods

At our company's Xmas party we had almost a physical fight over 开发者_如何转开发one issue: whether or not to allow empty lines in a function/method in our code (c/c++/c#). This is all about just single blank line, for example imagine code like:

 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 nonsensical mix, just to illustrate situation - first block of function loads data, second one fills some kind of data control and the blank line separates them.

One should also have written a comment before each 'block', but the important thing is that the for guys would place a blank line before that comment and the against guys would not.

For: Allows programmer to logically separate pieces of function so it improves readability as some kind visual cues for the eyes to follow

Against: Decreases readability and programmer should use comment for separating pieces of the function instead.

My personal opinion is to allow blank lines in functions, because without them long pieces of code look to me like a never ending stream of lines without any cues about where to find the stuff I'm looking for)

---

I think that an empty line in method body is a code smell. Read this blog post about this very subject: An Empty Line is a Code Smell. In short, empty lines in method body is a bad practice because a method should not contain "parts". A method should always do one thing and its functional decomposition should be done by language constructs (for example, new methods), and never by empty lines.

---

That will be awesome duel to watch. Just like the final scene in The Good, The Bad, and the Ugly but over method whitespace instead of gold.

Honestly, this shouldn't even matter unless you need to constantly mull over someone else's code in your team on a pretty frequent basis. Personally, I am all for whitespace as it gives a logical grouping. But it might not be the same for someone else. Heck, even I might change the way I group things over time. Grouped items that previously used to make sense might not anymore.

Regardless of how we group items, I think grouping is very important. We can argue over why empty lines are unnecessary, but the fact is that the brain can only handle a limited amount of information at a time. So if I can understand the function as composed of three subgroups for instance, instead of ten statements, that makes a lot of difference. And grouping by comments is subjective to your IDE. Most IDE's color them lightly than the rest of the code which gives that feel of separation, but that becomes IDE specific.

So to argue for the point, it's all about grouping. If a class becomes too big, we have to break it for the sake of understandability and maintenance. Similarly, if the sequential lines of code inside a method becomes too much too grasp, it must be broken down more methods or logically separated with a blank newline.

Also, if the argument is going nowhere, throw in some random stuff like how these empty lines relate to the Buddhist concept of nothingness bla bla..

---

"One size fits all" rules like this do not work.

There are valid arguments for and against each point of view e.g. I could counter your "long lines of code" argument by saying such functions should be broken into sub routines.

However, this is beside the point.

Saying one "MUST" insert blank lines is as nonsensical as saying one CANNOT insert blank lines.

BW's law in these situations is "use what works for you"

If this must be resolved, take a vote and have everyone agree to abide by the vote before the vote is taken (even you, if you loose).

That's my two cents.

P.S. My personal opinion is for blank lines.

---

Definitely for, although this question may be subjective.

Besides, I've learned to split up a method if it becomes too large rather can "compress" it by removing enters.

---

A physical fight? At a Christmas party? Sounds like a fun spot.

I'm in favor of whitespace as well when it improves readability. That's part of the reason why I'm also in favor of lining up curly braces: the extra whitespace sets off the block of code visually.

Most comments are clutter and don't help readability. If they don't add information to help understand code they're only getting in the way.

Sounds like I would have been fighting against the "no whitespace/add comments" crowd.

---

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

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

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

    return result;
}

If it's a moderately complex method with logically distinct blocks of code that don't require encapsulating in their own methods, I'll separate them with spaces as well. Anything that might equate to a 'paragraph' of code is separated with a blank line.

Most of the commenting I leave in the /// comment blocks at the top of the method.

---

I'm all for whitespace - it's an insignificant amount of memory usage that vastly improves the readability of code by cutting the program up into logical steps. This isn't a replacement for good comments, however. My commenting rule is 'try not to do the things that are irritating in other peoples code (which usually turns out to be not commenting - A simple '//do X and Y if Z says it's necessary' is a good level of detail for an individual comment I reckon)

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

Huge chunks of whitespaces can push code down off the screen however, which hinders the ability to look at the code and get a good overview, so it's best not to overdo it.

Like all things in programming it's down to case-by-case judgement, personal preference and a hint of moderation.