Making code more readable sometimes means knowing where to put nothing.
Programming has strict rules about the meaning of the code. And compilers don’t care how easy the code is to understand. It either follows the rules or not.
But as humans, we do care. Because if code is hard to read, then it’s hard to understand. And that increases the chances that mistakes will be made resulting in bugs. That’s assuming the project can be finished at all.
I’ve already explained many aspects of making your code more understandable from how to name variables, methods, and classes, to the proper use of comments. And there’s the whole subject of design patterns that can help structure your code into common designs that have evolved and been proven to work well.
This episode is about whitespace which includes spaces, tabs, and new lines. If you were to print your source code on plain white paper, then whitespace is anything that results in nothing being printed.
For example, take the placement of opening and closing curly braces. Some people prefer to put the opening curly brace at the end of the line that starts the block. An if statement would then have the if keyword followed by the expression in parenthesis and then an opening curly brace all on the same line. I think this style is liked by some because a lot of books take this approach. But if you think about it, a book needs to save space and having a curly brace on a line all by itself wastes a lot of space. When programming though, vertical space is usually not as much of a problem. And especially these days with the size of computer monitors as big as they are.
I like my curly braces to line up. Not only does this help me to read the blocks of code better but it’s consistent. Make sure to listen to the full episode for more explanation. Or you can also read the full transcript below.
Transcript
Have you ever tried stream of consciousness writing? This is a great way to get ideas down quickly without stopping to judge anything. You just keep the pen moving or keep typing keys without stopping and write down everything that comes to mind. You don’t capitalize anything or use any punctuation.
Now, have you ever tried to read the output of this? You’ll get ideas, sure. But it’s not easy to read.
Programming has strict rules about the meaning of the code. And compilers don’t care how easy the code is to understand. It either follows the rules or not.
But as humans, we do care. Because if code is hard to read, then it’s hard to understand. And that increases the chances that mistakes will be made resulting in bugs. That’s assuming the project can be finished at all.
I’ve already explained many aspects of making your code more understandable from how to name variables, methods, and classes, to the proper use of comments. And there’s the whole subject of design patterns that can help structure your code into common designs that have evolved and been proven to work well.
This episode is about whitespace which includes spaces, tabs, and new lines. If you were to print your source code on plain white paper, then whitespace is anything that results in nothing being printed.
This is not high school English class where lines have to be double-spaced and either single or double spaces appear after periods. Where the first lines of paragraphs are indented and your name appears in the top-right corner.
Some of this is about personal style but not all of it.
For example, take the placement of opening and closing curly braces. Some people prefer to put the opening curly brace at the end of the line that starts the block. An if statement would then have the if keyword followed by the expression in parenthesis and then an opening curly brace all on the same line.
I think this style is liked by some because a lot of books take this approach. But if you think about it, a book needs to save space and having a curly brace on a line all by itself wastes a lot of space. When programming though, vertical space is usually not as much of a problem. And especially these days with the size of computer monitors as big as they are.
I remember when having a 21 inch monitor was a big deal. These were tubes and not flat screen LCDs. One monitor took up an entire desk but it was well worth it. There would always be a line of people asking for these monitors whenever developers with one announced they would be leaving.
There’s more to this topic that I’ll explain right after this message from our sponsor.
I like my curly braces to line up. Not only does this help me to read the blocks of code better but it’s consistent.
Each of these blocks of code needs to be indented. This helps to visually group them together. What should you use for the indentation? Tabs or spaces? Some people like tabs because they’re quick to move through and easier to click at the right spot with a mouse. Just looking at the code, you usually can’t tell the difference between tabs or spaces. But here’s why I like spaces instead of tabs. Sure, you need to use 4 spaces for every tab but modern code editors let you type the tab key and they insert the spaces for you.
The real reason to use spaces is because you’ll sometimes need to view your source code in a simpler text editor. Something like notepad on Windows. Spaces will look the same in these editors. But tabs are often defined to be the width of 8 spaces. You’re indentation will slide the text way to the other side of the screen. And that’s if everything’s consistent. Just try opening a file that uses spaces in some places and tabs in others. It’ll be a mess.
There are no real rules here other than maybe consistency. Whatever you decide on, probably the most important thing is to be consistent.
One suggestion I’ll make about whitespace does have a benefit beyond the appearance of your code. Sometimes, developers will put statement on a single line if they’re highly related. A simple if statement followed by a single line of code to be run if the statement is true will sometimes all be placed on a single line.
I recommend against this. In fact, I recommend that you use opening and closing curly braces or whatever your language uses to begin and end blocks. Use these curly braces all the time. Even if all you have is a single line of code. the reason is because that single line of code often needs more code later as your program gets more features. But even more important than future expansion, to me is consistency.
Other than the curly braces, why should you put statements on their own lines? If you ever want to debug your code and stop at a specific statement with a breakpoint, then that statement needs to be on a line all by itself.
There are other places that whitespace helps. The obvious is putting spaces around operators. Sure, you can run things together by adding and dividing variables without any spaces between variable names and the operators but then it’s easy to miss operations and harder to read.
The exceptions are the unary operators. These are the ones that work with a single value such as increment and decrement. To me, it’s more understandable to not use any space at all between the unary operators and their value.
It all comes down to grouping. You can use whitespace effectively to group things together that belong together and separate things that are different. Be consistent and avoid being sloppy with, for example, extra blank lines scattered though your code.
I’m not saying don’t use blank lines. I use them all the time. But I make sure to use them consistently so they have meaning. When I see a blank line, I want it to mean that the previous code is done and something new is about to start.