Screen Layout

Screens are the window onto code. Every piece of code I've looked at in the last 20 years of so has been seen on a screen. However, before that I used a teletype and other typewriter type devices. The typewriters produced 8.5" x 11" (width, height) paper output. Yes I know that the some printers printed 132 - 160 characters per line but I did not use those much. A page in portrait mode (as it is known now) started out showing about 80 characters (fixed width 1/10" per letter). Modern laser printers in portrait mode can show easily show 106 characters in Courier New font.

Assembly language is where it all started. Assembly language has multiple fields in every instruction and it is important to get every field correct. So each instruction was written on a line along with a comment. When procedural languages came along programmers continued that style of writing, one procedural statement per line. Note that in those days that a page of paper had 66 lines on it, 60 or 63 if some white space was left at the top and bottom of the page. The math was 60 statements per page and a lot of white space on the right side of the paper.

Writing complex routines sometimes takes more than 60 statements and the logic is completely obscured. Sometime in the 70s I started writing assemply language with multiple statments on a line. If and loop statment bodies were indented. I used lines to emulate procedural language statments, i.e. chunks of code.

So back to screen sizes. Screen started as 4 x 3 ratio and are now 16 x 9, where the long side is horizontal. So why would anyone waste all that geography that is to the right of the left margin? I organize code in chunks that make sense being together on a single line. Of course "if" and "loop" blocks have indented bodies. A bunch of short statments are placed on a single line. Here is an example to two statements on a single line:

Sometimes rather than one space after the semicolon (i.e. ';') three spaces precede the next statement so that they stand out better as separate.

A long statement (one that exceeds the length of a line on the output medium) is split somewhere useful and the right hand part is placed on the next line but shifted to right so that end of the line is near the right margin:

The idea here is to associate the two lines visually and leave the function name in the clear.

So the whole width of the page is used for code. Once the printed page width is established by a print program (mine allows 106 characters in Courier New, one of the fixed width fonts) then the editor is configured to put a vertical line at the 106th character position. A fixed width font is used in programming so that the indenting is the same on the screen as it is on paper and is easy to arrange using spaces. Tab characters are replaced by spaces in my editor (as configured) so that there is no confusion about how tabs should be interpreted.

Code Blocks

Once upon a time a conditional statement used "If", "Elseif", "Else" and "Endif". It made perfect sence to align each of these keywords in the same character column on the page. They were easy to find in the clutter of a program:

That all changed in "C". Now blocks of code (still indented) are delimited by braces (i.e. "{", "}"). These characters are narrow and slightly different from parenthesese and brackets. So how are they to made really visible on a screen filled with characters. And how does one find the end brace visually once the opening brace is located? I settled on a non-tradional answer. I got flack for it too.

The opening brace goes on the same line as the conditional statement (or for loop or while loop, etc.). The closing brace is at the same indentation level as the body of the conditional. Find the body and move the eye straight down the page to the end brace.

I've seen conventions where the opening brace is placed on the next line (what a waste of a line). I've seen conventions where the closing brace is at the same indentation level as the "if" statement. The body is typically indented 4 or more spaces in these instances so the opening and closing brace are in the same column. But I find that my eye has trouble associating the two braces in a block, particularly when there are multiple nested blocks. I prefer the situation where the slim characters is linked (tied, associated with) other characters.

What about simple conditionals (e.g. if something then function call). What if that simple statement fits on one line. The tradional answer is 4 lines:

• First line is the condition
• Second line is the opening brace
• Third line is the function call indented
• Fourth line is the closing brace

If the line is too long to fit on one line, then break it as shown above perhaps after the conditional, perhaps after one of the arguments. Notice that the braces are missing. "C" and "C++" allow one statement after "if", "for", "while" statments (which end with a closing paretheses). Be watchful of this as there are times when an "else" clause is needed inside of a nested set of conditionals. The braces may be necessary to get the "else" to be attached to the correct "if" (you have been warned).

So a judgement call is made every time one of these lines is written. What is important to the reader? Is the condition important, yes. Is the function that is being called (well yes but only if the condition is true). Are the arguments important (yes, but only if the function is called). Left most stuff is more important than the rightmost stuff.

Motivation

So what is the motivation of all of the above comments? When I review code I want to see the whole code on the editor or debugger window. Please note that the window is defined as 106 characters wide and the height of the screen (less window borders). So my rule of thumb is no function be larger than will fit in the window. Do I violate that rule, sure. But if I do, then the function probably gets rewritten at some point to make better abstractions. Since a function should fit in one window then it is easier to do so if the whole widnow is used.