With time you realize that writing great code has a lot more to do with good habits than technical knowledge. Some developers find ways to write overly complicated instructions, even in simple languages.
This article will define “good code” as easy to read, visually appealing, and self-documenting. This rule of thumb will not help you write optimized code, meaning it will not directly improve the execution speed of what you write. Nevertheless, it will steer you away from essential performance slips!
The habit: make column 80 sacred.
A column is the position of a given character in a line of code, ranging from the leftmost character starting at zero. A file containing code contains multiple lines which have varying column width.
This column limit originates from multiple places; most notably, the first IBM punch cards have an 80 characters limit. Early digital computers would use them as a means of input for programs. The choice of this limit is debatable, one could argue that they come from the typical width of a typewriter. In most cases, it is merely a matter of reading ergonomics. Past this width threshold, the text becomes harder to read.
As an example, an unnecessarily complicated function. Theoretically, it is used to determine if a given string represents a widely accepted “vegetable.”
This is “valid” code, but it is not very kind for your co-workers because it is difficult to understand. If they have to maintain this library, they will have to put extra effort into guessing what it really does. In this case, what it does is not very abstracted. Everyone can relate to vegetables. In most cases, one-liner expressions like these can be used to manipulate many lower-level concepts — making it way worse.
Getting past column 80 may signal that you are writing carelessly complex functions. Not only that, but your brain also has to work much harder to keep in “cache” all the instructions before moving to the next line. It’s easy and fast to write, yet it’s hard and slow to read.
Here is a solution that brings the longest line to 57 characters:
The first thing you may notice is that it is perfectly fine to break down a list of elements into multiple lines. Many of us don’t use side-scrolling mouses or editors that quickly scroll to the right (ex: Vim). Visually the code looks far more inviting to be read as well.
You could argue that I just turned 7 lines of code into 20 lines of code, is that a bad thing? I also broke the logic into two separate functions, wasn’t one good enough?
A popular opinion is that codebases tend to be read much more often than written; code is meant to be read by humans. A computer will take these instructions and parse it into bytecode that it can understand. The resulting assembly instruction of these two examples will very likely be the same. So being terse in your implementation won’t make much of a difference for the processor.
If code size matters to you, compile it down with a uglifier before serving it over the network — it will do that job free of charge.
Getting across your edge-cases will force you to hit the web in search of solutions
Most likely, there are many ways to make this code better with stricter architecture and still keep it as a one-liner. But for the example sake, I decided to break it into two functions. My first issue was finding a solution to respect my column 80 limit. Doing so forced me to isolate the logic separately and made my code better.
The benefits of this are reusability and testability. If I need to validate only a single item for any reason, it will be much easier.
Some other accidental benefits:
- Fewer indentations are easier to read, flattening your code;
- Using placeholder variables is an excellent way to document your code;
- Breaking long lines is easier on the brain;
- Makes reading less imposing, more inviting and clearer;
- Allows you to have more horizontal tabs open while working;
- Force you to have a consistent coding style;
- Prevent you from writing a function that takes more than a parameter;
- Give you the motivation to write types or classes in more verbose languages like Typescript or Java instead of writing extended object/dictionary definitions.
Times where you may consider cheating:
- You don’t need to break long strings like error messages;
- When writing HTML or other template languages;
- Edge-cases were it would make your implementation harder to understand.
A habit that gets you curious.
Trust me, getting past column 80 can be a challenge at first. Getting across your edge-cases will force you to hit the web in search of solutions. Maybe you will find out other coding styles or some functionality of your language that you did not know before.
Even if you fancy verbose, statically typed languages, do not give up. There is always a way to fit things inside column 80 without making your linter angry at you.
Note that it is possible to visually display column 80 in most IDE’s. Here is a tutorial for VsCode, for vim simply use
set colorcolumn=80 in your configuration file to display a line at that column.
Would you like to learn about a commitment that will help you reduce your coding anxiety? Read my next article on the subject!