These rules, created by Rob Pike, help programmers write better code by keeping things simple and effective. Below, each rule is explained in plain language with examples to show how they work in real coding situations. I read and adapted them for my own understanding from the original site.
You can't always know which part of your program is slowing things down. Problems often pop up in unexpected places, so don't rush to "fix" the speed until you know exactly where the issue is.
Example Scenario: You're building a website, and it feels slow to load. You might think the image-loading code is the problem, but after checking, you find out the database query is taking too long. Without checking, you'd waste time tweaking the wrong thing.
Before you try to make your code faster, measure how it's performing. Only speed up the parts that are actually causing delays, and only if they're a big deal compared to the rest.
Example Scenario: Your app takes ages to process a list of names. You measure and find one function (say, sorting the names) takes 90% of the time. Focus on improving that function instead of tweaking other parts that barely affect speed.
Fancy algorithms (complex ways to solve problems) are often slow when you're working with small amounts of data, which is common. They take more effort to set up, so stick with simple solutions unless you're sure you're dealing with lots of data. Even then, check Rule 2 first.
Example Scenario: You're writing code to sort 10 numbers. A complex algorithm like quicksort might be overkill and slower than a basic bubble sort for such a small list. Use the simple one unless you're sorting thousands of numbers.
Complicated algorithms are harder to write correctly and more likely to have bugs. Use simple algorithms and basic data structures to keep your code easy to understand and reliable.
Example Scenario: You're coding a feature to find the shortest path in a game. A complex algorithm might be powerful but tricky to get right, leading to bugs like characters getting stuck. A simpler approach, like checking nearby paths first, is easier to code and test.
If you pick the right way to store and organize your data, the best way to process it often becomes obvious. Good data structures are more important than clever algorithms.
Example Scenario: You're building a to-do list app. If you store tasks in a smart way (like a list grouped by due date), finding overdue tasks is easy—you just check the “overdue” group. Poor data organization, like one messy list, makes it harder to write good code.
- Rules 1 and 2 are similar to Tony Hoare's idea: “Trying to make code faster before you know what's slow causes problems.” Always check first!
- Rules 3 and 4 follow Ken Thompson's advice: “When unsure, go for the straightforward solution.” They match the KISS principle (Keep It Simple, Stupid).
- Rule 5 was also mentioned by Fred Brooks in The Mythical Man-Month. A shorter version is: “Write simple code that uses clever data structures.”