I’m often told by my friends and colleagues that I use way to much whitespace. I guess I do use a little too much whitespace. I often add a line break almost after every line and large blocks of whitespace, often 3 or 4 lines because it helps me see what I’ve written and understand what I’ve written when I look back on it at a later time. I also think it just looks cleaner.
Although I can see two issues with this, 1) It can increase the file size of the source files, even just a line break every two or three lines can add up in a long file. I know that a good compiler will optimize all the white space out (I’m not actually sure, I think LLVM/Clang does this) but the source file is still large.
And 2) it may cause some people to think I’m embellishing my code to make it look longer and “bigger” to make others think I’m doing more work than I actually am (consider 3000 lines vs. 6000 lines, 3000 being newlines). Which I am not doing that by the way. Is using too much whitespace bad from a technical standpoint and/or a professional standpoint?
12
There’s two reasons why you should strongly consider not doing this:
-
Code is much harder to understand when you can’t see all the relevant parts at once. By inserting a blank line between most lines, you’re halving how much code you can see.
-
Consistency with other people’s code is important in group projects. It doesn’t matter too much which particular conventions the project follows as long as it’s consistent. It’s hard enough to understand large systems; it’s harder still when each part has different indentation schemes, naming conventions and idioms.
5
Whitespace is indeed useful it helps break up sections of text to make various parts more distinct and stand out “this is a block. Look at it in that context.”
Horizontal whitespace is used for indentation and scope to also give hints. One of the dangers of putting too much vertical whitespace in is that the eye looses the ability to track the indentation. In languages without {}, this can be disastrous for the context of the code.
That context is very important. If something isn’t on the screen, you can’t quickly scan back to it – you have to scroll to it. This can mean either losing the code you were just looking at and having to move the hand to the mouse. These things take time and some expenditure of mental energy. While it can be a small amount of mental energy, it is still some unnecessary expenditure.
Lets actually look at this and get some code. This is from _header_value_parser.py
The text doesn’t matter too much, but note that thats quite a bit less on the screen. One can’t even get the full method in the page. And there is questions about where some of the blocks line up – the eye doesn’t travel that well keeping things in line to far (it becomes more obvious in the full size image – does line 176 line up with the scope of 135 or 133?).
Its not about how many lines you are checking in (any one counting code checkin metrics is using source lines of code instead which discounts white space and may also discount comment lines). Its about keeping things in easy swap distance of the eye and the mind.
3
Is too much whitespace a bad thing?
Clearly:Yes. If you say, it is too much, then it is a sign, for something smelly going on.
I often add a line break almost after every line and large blocks of whitespace, often 3 or 4 lines because it helps me see what I’ve written and understand what I’ve written when I look back on it at a later time. I also think it just looks cleaner.
Your problem is not whitespace, your problem is clean code or better: a lack of clean code.
One lesson clean code teaches us is: breaking down large code blocks into smaller ones. I bet, every block you wrap in whitespache is a block, which could be chopped up into small handy pieces.
Try it with paranoia: Every function greater than 10 lines has to be broken up into smaller chunks. And in case you are writing OO: every class longer than 200 lines is too large.
Of course 10/200 lines is an arbitrary number, but if you follow this rule for a while, you will notice the effects: a) you won’t have whitespace blocks anymore b) your code gets more compact, readable and better to understand, and in the end: maintainable.
Although I can see two issues with this, 1) It can increase the file size of the source files, even just a line break every two or three lines can add up in a long file. I know that a good compiler will optimize all the white space out (I’m not actually sure, I think LLVM/Clang does this) but the source file is still large.
Why worring about filesize? We do not live in the 80ies and store everything on tape. We are in the age of Big Data. That is the wrong concern. And if you break up your blocks into readable chunks, the number of files and the size will increase. But don’t worry.
And 2) it may cause some people to think I’m embellishing my code to make it look longer and “bigger” to make others think I’m doing more work than I actually am (consider 3000 lines vs. 6000 lines, 3000 being newlines). Which I am not doing that by the way. Is using too much whitespace bad from a technical standpoint and/or a professional standpoint?
That is also a wrong concern. If you are measured by the LoC or the bytesize of your output, quit your job. Code should be measured in quality not quantity.
3
I recommend the Google Style Guides for the programming language you are using. I abide to these rules and they usually lead to clean-looking code. There are somethings I add myself (like 2 blank lines between functions) but overall I really like the Google Style Guides.
Update:
The different style guides vary a bit per language, as these are put together by different engineers who devote all their time working in that language, so what they have written down is what they believe leads to clean-looking code. It seems that overall, the rule of thumb is to only use blank lines to distinguish code groups. Multiple consecutive blank lines are hardly ever encouraged. Here’s some excerpts from these guides:
Java
A single blank line appears:
- Between consecutive members (or initializers) of a class: fields, constructors,
methods, nested classes, static initializers, instance initializers.- Exception: A blank line between two consecutive
fields (having no other code between them) is optional. Such blank lines are used as needed to
create logical groupings of fields.
- Exception: A blank line between two consecutive
- Within method bodies, as needed to create logical groupings of statements.
- Optionally before the first member or after the last member of the class (neither
encouraged nor discouraged). - As required by other sections of this document (such as Section 3.3,
Import statements).
Multiple consecutive blank lines are permitted, but never required (or encouraged).
Python
Two blank lines between top-level definitions, be they function or class definitions. One blank line between method definitions and between the class line and the first method. Use single blank lines as you judge appropriate within functions or methods.
C++
Minimize use of vertical whitespace.
This is more a principle than a rule: don’t use blank lines when you don’t have to. In particular, don’t put more than one or two blank lines between functions, resist starting functions with a blank line, don’t end functions with a blank line, and be discriminating with your use of blank lines inside functions.
The basic principle is: The more code that fits on one screen, the easier it is to follow and understand the control flow of the program. Of course, readability can suffer from code being too dense as well as too spread out, so use your judgement. But in general, minimize use of vertical whitespace.
Some rules of thumb to help when blank lines may be useful:
- Blank lines at the beginning or end of a function very rarely help readability.
- Blank lines inside a chain of if-else blocks may well help readability
Objective-C
Blank lines before and after @interface, @implementation, and @end are optional. If your @interface declares instance variables, a blank line should come after the closing brace (}).
Unless an interface or implementation is very short, such as when declaring a handful of private methods or a bridge class, adding blank lines usually helps readability.
I only put the information here regarding vertical whitespace, but some of the guides also have info on horizontal whitespace and a lot more formatting information (comments, blocks, indentation, etc…)
And the project is open source so if you have any suggestions you could email one of the project owners.
2
It’s depend of what you mean by too many space. For me it’s important and primordial to use space for improve the readability of your code. Use one line free to seperate few block in function, free space between function and class it’s good, and allign symbol with few language can be cool also:
sub my_function {
my $arg = @_;
my $a = 42;
my $b = 50;
my $sum = $a + $b;
my $map = {
key => 'value',
second => 'second value'
}
if ( $sum > $ arg ) {
return $sum
}
return;
}
A little example what I love, hovewer if you use too my line space is not good. For example five free line between the last return and the conditional structure, for me it’s a bad idea.
1
Beside the other good answers, there are also tools issues. Good text editors will provide facilities (like highlighting) to match opening and closing brackets. But some of them, like gedit, won’t do it when they are too far away. Of course it means you should also avoid long methods, but too much vertical blank can also harm.
Blank lines can be usefull to help making a program easy to read if they are used to separate logical blocks (like paragraphs in a text). If everything is separated that’s like if nothing was.
You can have too much whitespace – usually its annoying to see a blank line between block and the ending curly brace, eg:
if (x)
{
// do something
// do more
}
That annoys me a lot. But then, I like multiple blank lines between functions – 1 line is enough for logical blocks within a function, so 2 makes each function stand out that little more.
Within functions, you do not want to space it out so much that it looks like the logical blocks within it are functions themselves. You’re trying to break up a big block of text so its easy to read (like paragraphs in a book) without introducing extraneous white that starts to disrupt reader’s ability to group these blocks together.
So: a quick standard for you:
1. indent correctly.
2. single blank line between blocks, where appropriate
3. multiple blank lines between functions.
4. nowhere else.
Stick to that and you’ll have happy colleagues and tidy code.
It definitely depends on the various factors others have mentioned.
There are some circumstances where I want more whitespace, e.g. I may prefer
class Thing
def method1
stuff
end
def method2
stuff
end
end
to
class Thing
def method1
stuff
end
def method2
stuff
end
end
because if those methods get long, having the whtespace lines between them is helpful.
So as a general guideline for code, for % of whitespace lines, I would look for a figure of between 10% and 30%. Less than that and you have long algorithms, more than than that and you may be scrolling up and down and losing context and visual ‘see together’ grouping.
However, that said…
for some uses, having it ‘all on one screen’ is really helpful.
A good example if my .bashrc file which had got to 3 or 4 ‘screens worth’ and was leading to more:
- duplication for same settings
- conflicting uses of same settings
- forgetting what settings do
So in this case, I went to a lot of effort to ‘compact’ it down. In this case not just whitespace but making if then constructs fit on 1 line, e.g.
test -f ~/.bash_aliases && . $_
and was able to get it down to 27 lines which I can see all at once, even in a small terminal window, i.e.
Finally, the two issues you mention – file size and padding length are not factors that any programmers I know and respect would pay attention to – remember 100GB is a hundred thousand million bytes. Extra line spaces would just be considered to be your preference for line space. If the code actually worked this would usually be a relatively minor issue, though with a team, one that should be agreed on.
When it comes to whitespace, file size and compile performance should be of no concern, and whitespace should have no effect on compiler output.
It’s all about readability, but readability of a given sample will be different for different readers.
As has been stated in other answers, too much vertical whitespace has the effect of lifting bits of code out of context, which can impair understanding when that context is necessary to proper understanding. I will generally never separate anything by more than one blank line – enough to set off a bit of code without sacrificing context. I worked with a developer who insisted upon four blank lines between functions. He found it helpful for readability, I felt was excessive, contributed nothing to readability and that it hampered navigation.
If you are working in a team, you should have a style guide and work to that (whether home-brewed or something more widely distributed); presumably it will accommodate the majority of the readers who will have to work with that code.
Whitespace in code can be used to create emphasis, a blank line before and after a block of code can be used to indicate that the code in the block is a little closer tied to itself than it is to the surrounding code. If you put a blank line between every line of code you have prevented yourself from using this method of emphasis, so you use multiple blank lines where you need this emphasis. You gained nothing in terms of emphasis, you just gained a lot of blank lines.
You think your code looks cleaner. The funny thing about the state of being clean is that it is actually the lack of anything that is considered dirty. Looking clean, as opposed to actually being clean, simply means that you can’t see the dirt. So yes, blank lines a plethora undoubtedly does make your code look cleaner as it limits how much code is visible at the same time, and therefore also how much code uncleanliness is visible at the same time. But your code simply looking clean does nothing to help you or anyone else write or maintain it. On the contrary, being able to see the dirt is a prerequisite for being able to deal with it.
There is a somewhat similar argument to be made about the much more widespread practice of excessive use of spaces, take a piece of code like:
while ( x > y || foo != bar || ! ( a in b ) ) {
By using a style with no default spaces a few spaces could have been used to emphasise the three distinct parts of the condition:
while(x>y || foo!=bar || !(a in b)){
If you have a hard time getting used to cutting down on whitespace consider configuring your editor to use a bigger font and/or more linespacing, then at least your colleagues can read your code without hassle, and given time you may be able to gradually change your settings towards normal.
Adding lots of whitespace into a function may break it up into handy blocks, but it conveys no useful information.
If you feel the need to add more than one blank line between sections, you should also be adding a comment to explain what the next bit of code is going to do.
Plus, as Thomas Junk has pointed out, over-long functions would be better split into smaller, more managable ones.