Eugene Kirpichov (antilamer) wrote,
Eugene Kirpichov
antilamer

Category:

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

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

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

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

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

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



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

  • The Dataflow Model

    В VLDB вышла статья от нашей команды про унификацию streaming/batch, event-time processing, windowing, triggers, вот это все. The Dataflow Model: A…

  • Коллеги рассказали задачку

    Есть бесконечная река с пристанями, пронумерованными всеми целыми числами (..., -2, -1, 0, 1, 2, ...). По реке плывет корабль-призрак, из неизвестной…

  • Про подкаст DevZen

    С большой радостью, благодаря gliv, послушал подкаст http://devzen.ru/episode-0038, где обсуждался в т.ч. и Cloud Dataflow (начало…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 59 comments

  • The Dataflow Model

    В VLDB вышла статья от нашей команды про унификацию streaming/batch, event-time processing, windowing, triggers, вот это все. The Dataflow Model: A…

  • Коллеги рассказали задачку

    Есть бесконечная река с пристанями, пронумерованными всеми целыми числами (..., -2, -1, 0, 1, 2, ...). По реке плывет корабль-призрак, из неизвестной…

  • Про подкаст DevZen

    С большой радостью, благодаря gliv, послушал подкаст http://devzen.ru/episode-0038, где обсуждался в т.ч. и Cloud Dataflow (начало…