Keep It Short & Simple

Posted 2025-12-15 22:20. Tagged development, Stacken.

Most experienced programmers know that KISS means Keep It Simple, Stupid. But should it? I think a better interpretation would be Keep It Short (and) Simple?

It is good that people know they should keep their programs simle – and that some even does. I don’t doubt that the edgyness of calling code—and the people who wrote it—stupid is part of why the KISS meme is so well known, but I have two objections.

The first is that the world at large, and maybe the the programming community specifically needs more friendlyness, compassion, and encouragement, and less of beeing mean is cool.

The other thing is that the whole point of the KISS rule is that code should be easy to read. Program code not only needs to do the right things when executed, is should also be possible to maintain, adjust and correct. To be able to maintain the code, someone needs to understand it. That someone may be a new developer on your team or someone taking over after you quit. Or it may be yourself a few months or years later.

When it comes to understanding the code of a program, one obstacle is way bigger than all others. You may have objections about goto, global mutable state or about to much or to little use of map/reduce, ansynchronous primitives, and so on. All of that is secondary. The most common reason for not beeing able to understand some code is not that it is too complicated, but that it is just too long.

So always try to make your code as short and readable as possible. If using an advanced feature of the language you are writing the program in makes the code a few lines shorter and more readable, you should consider using that feature. You can assume that future readers of your code knows the lanugage. You must not assume that the people reading your code already knows what your program is trying to do or how!

This is of course not saying you should use one-character names and remove all optional spacing. Use reasonable names for everything, and format the code according to best practice for the language (most modern languages has those conventions formalized in a formatting tool or linter. Use that! And use it with as few customizations as possible).

Keeping things reasonably short is needed at all levels. A line should not be too long, a function should not have to many lines, a file should not contain too many functions, a catalog should not contain too man files and the entire directory structure of the program should not be too deep. If you often break out very short functions you end up with too many functions instead (and the extra work of finding reasonlable names and maybe writing documentation for them). It’s all about finding the right balance.

One powerfull way of making the code shorter is to use things that’s already there. Foundational data structures and algorithms are often provided in the stadard library (or in external libraries if you are writing Javascript). More specific things, like parsers for different file systems, clients for network protocols, etc exists in external libraries (or that standard library if you are writing Python). But take care—the list of external requirements is also a thing that should be kept as short as possible. Here, too, it’s all about finding the right balance.