When I write code, I try to group lines of similar code together, then leave a blank line and write another block.
I believe this contributes to the neatness and readability of the code.
I'm not a big fan of bunching stuff together without any line spacing. It looks like hell, it's hard to read and it's difficult to follow.
One of the teachers I had, downgraded one of my assignments because I had spaced my code logically. He said, 'When you have to read code all day in the real world, you won't put this line spacing in and you'll be thanking me." Of course, I never did and never will thank him.
Now that I'm in the real world, most of the code files I see that have absolutely no line spacing are poorly written and poorly thought out.
This is probably more prevelant in VB type languages than in C type languages, but the same concept applies.
Two questions come to mind:
- Where do you leave a blank line in your code?
- How much line spacing is too much?
Since we don't have an example of your personal idea of "logical" line spacing, we can't really say whether or not you deserved to be downgraded.
I tend to group similar statements or steps in a sequence together before spacing (such as variable declarations, looping, etc.)
I know this is an old question, but I tripped over it doing a search for something else, and had an observation: look at the existing answers. They're generally short, yet they contain blank lines.
That's what paragraphs are. As in writing, lines are a quick, visual way to separate concepts. It doesn't mean each paragraph above should be broken into a separate answer; it doesn't mean each code "paragraph" should be broken into a separate method.
It's a silly complaint. If it were still possible to talk to that professor, I'd explain what "wall of text" means.
We have a coding standart that states that we should not put more than one blank line in a row. All the other is up to developer. In practice we do as you say - try to group logically connected lines into groups and isolate them with blank lines.
Not to sound pretentious, but I think of blank lines in code as having a similar function to phrase marks in music notation, or line breaks in poetry: they communicate intent to the reader without changing the semantics of the content.
Here's a method I just copied and pasted from a project:
What do the blank lines do here? They clarify that there are basically three different kinds of initialization taking place in this method. If I add a new property that needs to be initialized on startup, I know where I'm going to put the line that initializes it. The blank lines also hint at how I intend to refactor this function if it doubles in size.
The risk of using blank lines is the same as the danger of any other kind of implied meaning: it's implied. The implication you're making when you write the code may not be the implication that the person reading the code understands.
But mercy, that's no reason not to use them.
In my opinion, adding a blank space to your code is a hint that you should split your function into smaller parts. Cleaning up your code by adding spaces is preferable to a mile long list of unseparated lines. Cleaning up your code by separating out smaller functions is better.
My rule of thumb is:
But generally I agree that many large functions with lots of white space should be broken into smaller functions.