Sixty Column Rule
A take on the classic 80 column rule, the 60 column rule is a coding guidline which states that a line of code should not exceed more than 60 characters. It is an experimental rule that I am currently enforcing with all my more recent programming project.
Motivations
My initial motivation for trying out such a crazy idea came after acquiring a GPD Pocket 2, which only has a 7 inch screen. While using the device, I found myself wanting to use larger beefier fonts for easier readability. When dialing in comfortable settings, the total line width of the screen ended up being around 70 characters, less than the desirable 80 characters. So, I decided to see what it would be like to code with 60 column rule. 60 is large enough to be functional, but small enough to force noticeable changes in workflow.
My interest is in seeing how using the 60 column rule changes my coding style and programming behavior.
Thoughts so far
Here is a list of some self-observations. In no particular order.
Mono-Window setup
I almost always have only one window at a time, and at most 2. When I do split, it always has to be a horizontal split, but the vertical split is too skinny. As a result, less multi-tasking, less jumping between files.
When split, each window only shows 16 lines at a time, so the information conveyed is very limited.
Information Overload on larger screens
I am genuinely used to the screen size now, to the point where larger screens like my 15 inch MBP give me information overload. Even my 10-inch chromebook feels roomy now.
Outside projects are difficult
Most code-bases are incompatible with a screen this size, so it can be very tough navigating third-party code. This set-up really only works with projects written in this setup.
The good news is that projects written in this setup can be viewed in larger screens quite nicely.
Terser + skinnier coding style
Programs now are visually terser and skinner. In C, I am back to smaller functions with one-letter variable names. This isn't too much of a cognitive load because the functions are usually quite small in scope. Usually not confusing. Usually.
Function arguments are broken up into their own lines. Emacs does an auto-align which I have grown to appreciate. I hate being dependent on such things, but sure does look great.
Org-mode header folding is mission critical
Screen real-estate is precious, so I have come to be dependent on the header folding/unfolding to show or hide information. As a result, what I see on the screen is exactly what I need to see.
From a programming, this makes abstraction more important. If I can't see the code, I can't expect to remember exactly how it works. Breaking things up into components that fit into a single screen becomes more important.
Again, it makes me feel a bit uneasy knowing how dependent I am on this feature that is only available through the giant that is emacs, but things work fine for now.
Some interesting links
80x25: an thorough investigation on the origins of the 80x25 dimensions.
IBM,Sonic Delay Lines, and the History of the 80x24 Display: Not fully read yet. Appears to be a response to the 80x25 article above. More detail on why we have this standard display size.
home | index