Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная штука! Будем делать их побольше!

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

Простота

без лишних дополнений, изменений или усложнений
Простота является основным принципом. Все остальные принципы должны быть принесены в жертву простоте устройства Arch Linux. Простота реализации более важна, чем интуитивно понятный интерфейс.
Элегантность

сочетание простоты, мощности, эффективности, качества и продуманного дизайна
Французский летчик, авантюрист и писатель, Антуан де Сент-Экзюпери дал нам, возможно, лучшее определение инженерной элегантности, когда сказал: "конструктор осознаёт, что он достиг совершенства не тогда, когда нечего добавить, а когда нечего отнять".
Все же простота чуть-чуть важнее элегантности.
Универсальность

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

лёгкость или быстрота, удобство
Простая, элегантная и универсальная система должны быть удобной, где это возможно, но рациональность может быть принесена в жертву всем вышеперечисленным принципам. Ей следует пожертвовать, когда простота реализации находится под угрозой. Когда рациональность страдает в связи с усложнением пользовательского интерфейса, его следует реализовать без нагромождений.