Писать так, чтобы при прочтении любопытство вызывали только действительно нетривиальные участки.

— Не давать концептам "остроумные" имена, за исключением случаев, когда другого достаточно выразительного имени просто не существует (т.е. когда все неостроумные имена не раскрывают чего-то очень важного в этом концепте)
— Соблюдать одинаковый стиль во всем до мелочей (именование, порядок вызовов какого-нибудь API, форматирование однострочных if'ов итп)
— Разумеется, не делать орфографических ошибок — взгляд об них очень сильно спотыкается
— Не бояться небольшой избыточности в именах
— Не бояться небольшого дублирования кода
— Не бояться неэффективности алгоритма (не обрабатывать особым образом какие-то случаи, которые можно обработать чуть более эффективно — обработайте так же, как все остальное — код будет понятнее и, скорее всего, корректнее).
— Минимизировать объем контекста, необходимого для понимания фрагмента кода (например, для понимания фрагмента, использующего некоторый тип, надо помнить, что это за тип; аналогично вызов метода и т.п.). Поэтому и хорошо иногда не выделять кусок кода в метод, т.к. в своем естестве и в контексте окружающего кода он воспринимается быстрее, чем вызов этого метода.

Я даже, пожалуй, отказываюсь от своего мнения "не используйте паттерны или имена предков в названиях классов" (типа CachingFooFactory). Пусть там, где этот класс используется, будет сразу видно, что это именно caching, именно foo, и именно factory.

Чем больше в коде симметрии, чем лучше ощущается похожесть похожего, тем лучше. Пусть при прочтении возникает ощущение "Так, тут какая-то тривиальщина написана, идем дальше". Не надо от этого избавляться и сжимать код по Хаффману. Мне кажется, мозги хорошо заточены на восприятие множества похожих вещей с небольшими отличиями, и на восприятие отличий в контексте множества похожих вещей, но куда хуже заточены на on-the-fly инстанцирование абстрактных концептов.

Избавляться от симметрии надо тогда и только когда, когда это явно увеличивает поддерживаемость…