When you write programs, there are moments when you want to squeeze something into one brilliant line or use an ingenious solution others wouldn't easily think of. Short, clever code feels like proof of skill. But when that code breaks a few months later, even the person who wrote it often has to stare at it for a long time to work out what it meant. The rule of thumb that pinpoints this situation is “Kernighan's Law.”
Put simply, Kernighan's Law is the principle that “finding and fixing bugs is twice as hard as writing the code in the first place, so if you write code as cleverly as you can, you won't be able to fix it yourself.” This advice to put clarity ahead of cleverness is still widely quoted among programmers today.
In this article, we will look in turn at the background of Kernighan's Law, what the sentence means, misunderstandings surrounding the law, and how to put it to work in practice.
Why Clear Code Outlasts Clever Code
A Sentence from Bell Labs
The author of the line, Brian Kernighan, is a Canadian-born computer scientist who worked at Bell Labs in the United States. Together with Dennis Ritchie, he wrote the book regarded as the textbook of the C language, and he was also deeply involved in the development of Unix. The K among the three letters in the name of the text-processing language awk comes from his surname, and since 2000 he has been teaching students at Princeton University.
- Source (The Elements of Programming Style): The sentence appeared in The Elements of Programming Style, which he published in 1974 with his colleague P. J. Plauger.
- Second Edition: The second edition came out in 1978, and the sentence in question is in Chapter 2, which deals with expressions.
- Motivation (Textbook Examples): The two authors drew out rules for good code by rewriting, one by one, the sloppy FORTRAN and PL/I code found in textbooks of the time.
The book's title is modeled on The Elements of Style, the famous writing guide. The idea that runs through the whole book is that, just like good prose, good code should be free of clutter and clear in meaning.
What “Twice as Hard” Means
The original consists of two sentences: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” Here, debugging means finding and fixing bugs, the errors inside a program.
(1) Fixing is harder than writing
When you write code, your intent is vivid in your mind, but when you hunt for a bug you have to trace backward to find where that intent and the actual behavior diverged. It is harder because the mistake is hiding somewhere in a part you believed was correct.
(2) Use up all your cleverness and nothing is left
If you write code by pushing your ability to its limit, your ability will fall short when it comes to debugging, which is twice as hard. “Twice” here is not a precisely measured figure but an expression emphasizing that the gap is large.
(3) So write clearly
The conclusion is to save your cleverness. If you write code from the start so that it can be understood with about half your ability, then even when problems arise later, you'll have enough strength left to find the cause. In fact, the same book also includes the rule “Write clearly – don't be too clever.”
Misunderstandings About the Law
Because Kernighan's Law is short and witty, it is sometimes read in ways that differ from its original meaning.
Does It Mean Don't Use Difficult Techniques?
The law does not forbid difficult techniques as such. Using a sophisticated method where it is truly needed is different from deliberately twisting a problem that could be solved simply. What you should be wary of is the habit of writing hard-to-understand code to show off. Code golf, a game of cutting the number of characters as far as possible, is a fun brain exercise, but if you put that kind of code straight into a real service, the people who have to fix it will suffer.
Another Reading: Kernighan's Lever
Swedish programmer Linus Åkesson reread the sentence as “Kernighan's Lever.” In his interpretation, the struggle to fix code beyond your own skill is exactly what makes your skill grow. However, that applies to a learning setting; for code that many people use for a long time, the original advice is the safer one.
Putting Kernighan's Law to Work in Practice
Kernighan's Law leads to a number of habits that make code easier to read.
(1) Think of the reader first
Code is written once and read many times. Choose clear names so that you a few months from now, or a colleague seeing it for the first time, can understand it right away, and don't cram too much work into a single line.
(2) Make it right, then make it fast
The same book advises, “Make it right before you make it faster.” Twisting code for performance can wait until you've confirmed where it is really slow.
(3) Choose code that is easy to fix over code that is short
These days AI tools can generate complex code in an instant, but the responsibility for understanding and fixing that code still lies with people. It's safer not to accept code you can't explain as is.
In a 1979 piece, Kernighan also said that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements. In other words, simple code that you can reason through calmly, rather than flashy tools, is the foundation of problem solving.
Kernighan's Law isn't telling you to hide your skill; it's advice about where to use it. Ten ordinary lines that still read easily tomorrow will ultimately save more time than one clever line written today.
Writing only as cleverly as your own mind can unravel again: that is the first step toward code that lasts.
