Оригинал: Rob Pike’s 5 Rules of Programming
Роб Пайк — один из создателей Go, Plan 9 и UTF-8 — сформулировал пять правил программирования. Эти правила появились как часть заметок к книге «Notes on Programming in C» и отражают философию простоты, которая позже легла в основу языка Go.
Оригинальный текст
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’re much harder to implement. Use simple algorithms as well as simple data structures.
- 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’s famous maxim “Premature optimization is the root of all evil.”
Ken Thompson rephrased Pike’s rules 3 and 4 as “When in doubt, use brute force.”.
Rules 3 and 4 are instances of the design philosophy KISS.
Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to “write stupid code that uses smart objects”.
Перевод
5 правил программирования Роба Пайка
Правило 1. Невозможно заранее сказать, на что программа будет тратить время. Узкие места возникают в самых неожиданных местах, поэтому не пытайтесь угадывать и вставлять оптимизации, пока не докажете, что узкое место именно там.
Правило 2. Измеряйте. Не занимайтесь оптимизацией производительности, пока не провели измерения, и даже тогда — только если одна часть кода подавляюще доминирует над остальными.
Правило 3. Сложные алгоритмы работают медленно при малых n, а n обычно мало. У сложных алгоритмов большие константы. Пока вы не убедились, что n часто будет большим, не усложняйте. (И даже если n станет большим, сначала примените Правило 2.)
Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо труднее реализовать. Используйте простые алгоритмы и простые структуры данных.
Правило 5. Данные решают всё. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. Центральное место в программировании занимают структуры данных, а не алгоритмы.
Правила 1 и 2 Пайка повторяют знаменитый афоризм Тони Хоара: «Преждевременная оптимизация — корень всех зол».
Кен Томпсон перефразировал правила 3 и 4 так: «Если сомневаешься — используй грубую силу».
Правила 3 и 4 — частные случаи принципа проектирования KISS.
Правило 5 ранее сформулировал Фред Брукс в «Мифическом человеко-месяце». Его часто сокращают до: «Пиши глупый код, который использует умные объекты».
Примечание
В оригинале цитата «Преждевременная оптимизация — корень всех зол» присваивается Тони Хоара, однако в действительности автором является Дональд Кнут:
There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Дональд Кнут, «Structured Programming with go to Statements», Computing Surveys, Vol. 6, No. 4, Декабрь 1974, страница 268 (ссылка, 8 страница pdf файла)
Теги: