Приглашение к троллингу

antilamer — 16.04.2010 Один из компонентов достижения цели "писать хороший код и не писать плохой" - таков:
Писать так, чтобы при прочтении любопытство вызывали только действительно нетривиальные участки.

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

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

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

Избавляться от симметрии надо тогда и только когда, когда это явно увеличивает поддерживаемость (например, дублирован сложный, большой, хрупкий или изменчивый код).



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

Оставить комментарий

Популярные посты:

• Ранее
• Архив