While compilers generally don’t care about how code looks as long as it follows the rules on syntax. Those rules generally are there for the convenience of the compiler and not for to make the code easy to read by humans. In fact there is an annual contest to write the least understandable C program in the world. The problem is that programs that are hard to read are also generally difficult to understand and debug.
There was a time most programmers used a program of a type called “PrettyPrint.” This was a program that took source code and reformatted it to make it easier to read. Programmers might not pay much attention to how a program looked but when they were ready to print it out for debugging, code reviews or to collect in hard copy documentation they would run the source through one of these programs. The program would use indentation to show how decision structures and loops were nested. They would add white space to separate different tokens (symbols, variables, operators, etc) and generally pretty up the code.
When I was teaching and students brought unformatted code to me for debugging I would often ask them to first clean up the formatting. IF there was no PrettyPrint program or IDE feature available they would have to do it manually. It meant more work for them initially but the improvement in debugging speed was always worth it. Good indentation helps to determine if loops or decision structures are nested properly. Spaces around operators often helps spot typographical errors. IN general the use of white space makes reading everything much easier. Finding bugs is difficult enough without the code itself being difficult for the eye to parse.
One thing I like to do with printouts of code is to draw lines connecting the start and end of all loops and blocks of code in nested decision structures. This is much easier when the code is indented. Often times the act of drawing these lines is enough to make it clear where incorrect End If statements or closing curly braces are. This activity has made believers (in the value of formatting) of any number of students over the years.
Today a lot of IDEs and code editors will take care of some formatting while code is entered. In fact when code doesn’t look nice and indented this is often an early clue that the IDE is confused about what the code is trying to do. If the IDE is confused the compiler is probably going to be confused as well and that is never a good thing.
The Visual Studio IDE will format code either as it is entered or on command. Others probably do as well. It is a powerful tool to call an unformatted source file into an IDE, select a section of code and then ask the IDE to format it correctly. Visual Studio has some options to change the formatting used to meet different coding standards. For example haw are the curly braces formatted? Are they on their own line or at the end of a line?
Today there is little excuse for code that is unorganized and difficult to read. The tools that are available for good formatting make readable code easy for even the most lazy of programmers. Still I think it is important to explain to beginner programmers just how important that formatting is. Development groups don’t put all that effort into IDE formatting tools for the fun of it. Sometimes how the code looks really does matter. Good coders almost always have good looking (easy to read) code.
This is the nineteenth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this “proverb” are of course very welcome here.