rob_pike_s_5_rules_of_programming
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| rob_pike_s_5_rules_of_programming [2026/01/31 06:22] – created appledog | rob_pike_s_5_rules_of_programming [2026/01/31 06:23] (current) – appledog | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | from: https:// | + | = Rob Pike's 5 Rules of Programming |
| + | * from: https:// | ||
| Rob Pike's 5 Rules of Programming | Rob Pike's 5 Rules of Programming | ||
| - | | + | Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. |
| - | | + | Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. |
| - | | + | Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) |
| - | | + | Rule 4. Fancy algorithms are buggier than simple ones, and they' |
| - | | + | Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. |
| Pike's rules 1 and 2 restate Tony Hoare' | Pike's rules 1 and 2 restate Tony Hoare' | ||
rob_pike_s_5_rules_of_programming.1769840537.txt.gz · Last modified: by appledog
