Пишите программы, которые делают одну вещь и делают её хорошо.
Пишите программы, которые бы работали вместе.
Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс».

Rob Pike
* Правило 1: Вы не знаете, где программа начнёт тормозить. Узкие места возникают в неожиданных местах, поэтому не стройте догадки и изучайте скорость работы программы до тех пор, пока не удостоверитесь, что узкое место найдено.
* Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.
* Правило 3: Изощрённые алгоритмы являются медленными, если n мало, а n обычно мало. В изощрённых алгоритмах присутствуют большие константы. До тех пор, пока вы не убедитесь, что n часто становится большим, избегайте изощрённости (даже если n становится большим, вначале используйте правило 2).
* Правило 4: Изощрённые алгоритмы чаще подвержены ошибкам, чем их простые аналоги, также их гораздо сложнее реализовать. Используйте простые алгоритмы наряду с использованием простых структур данных.
* Правило 5: Данные преобладают. При правильной и хорошо организованной структуре данных, алгоритмы становятся очевидными. Структуры данных, а не алгоритмы, являются центральной частью в программировании.
* Правило 6: Правила 6 нет.

Правила 1 и 2 Пайка перефразированы Тони Хоаром в известную аксиому «Преждевременная оптимизация — корень всех зол». Кен Томпсон перефразировал правила 3 и 4 Пайка так: «Если сомневаетесь, используйте перебор всех возможных комбинаций». Правила 3 и 4 являются частными положениями философии дизайна KISS: Keep It Simple, Stupid (будь попроще, тупица). Правило 5 было предварительно сформулировано Фредом Бруксом в книге «Мифический человеко-месяц». Правило 5 часто сокращают до «пиши тупой код, который использует умные данные».

Эрик С. Рэймонд в своей книге «Искусство программирования в UNIX» подытожил философию UNIX как широко используемую инженерную философию KISS.

* Правило Модульности: Пишите простые части, соединяемые понятными интерфейсами.
* Правило Ясности: Ясность лучше заумности.
* Правило Композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
* Правило Разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
* Правило Простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
* Правило Экономности: Пишите большую программу только когда можно продемонстировать, что другими средствами выполнить необходимую задачу не удастся.
* Правило Прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
* Правило Надёжности: Надёжность — дитя прозрачности и простоты.
* Правило Представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
* Правило Наименьшего удивления: При разработке интерфейса всегда делайте как можно меньше неожиданных вещей.
* Правило Тишины: Если программе нечего сказать, пусть лучше молчит.
* Правило Восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
* Правило Экономии: Время программиста дорого; сократите его, используя машинное время.
* Правило Генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
* Правило Оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
* Правило Многообразия: Отвергайте все утверждения об «единственно правильном пути».
* Правило Расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.

Большинство из этих норм принимается вне сообщества UNIX — даже если это было не так во времена, когда они впервые были применены в UNIX, то впоследствии это стало так. К тому же много правил не являются уникальными или оригинальными для сообщества UNIX. Тем не менее, приверженцы программирования в UNIX склоняются к тому, чтобы принять комбинацию этих идей в качестве основ для стиля UNIX.

* «UNIX прост. Но надо быть гением, чтобы понять его простоту» — Деннис Ритчи.
* «UNIX не был разработан так, чтобы отгораживать своих пользователей от глупостей, поскольку это отгородило бы их от делания умных вещей» — Дуг Гвин.
* «UNIX никогда не скажет „пожалуйста“» — Роб Пайк.

От редактора:
Все вышеизложеное в наше время начинает противоречить тому, чему учат в школах и институтах. Нас учат ООП, сложным алгоритмам, основаным на математических формулах и законах, там где в этом совсем нет надобности , работать и создавать "легки и понятный" навороченые графические интерфейсы забывая о простоте.

paly@jabber.zp.ua