Предпосылки появления code style-а

by Темных Сергей 15.03.2009 23:21:00
для начала следующие предпосылки:
1. Первично, что код - это штука, с помощью которой автор(программист) рассказывает другому человеку, как по его мнению правильнее решать данную задачу, а уже вторично - что это еще и рассказ машине.

2. люди разные, и программисты к удивлению тоже. у кого память хорошая, у кого-то плохая, кто-то быстро читает, кто-то медленнее, кто-то схватывает слету, кому-то надо подумать и т.д.

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

4. люди в среднем одновременно оперируют только 3-7 понятиями, и забывают предыдущую информацию буквально за секунды


несмотря на то, что в программисты идут, в первую очередь, люди, которые могут одновременно оперировать 173 понятиями, и которые помнят всё, что было начиная с 9 месяцев до начала их рождения, при написании кода надо учитывать:
этот код будет осмысляться другим человеком,
человек будет пытаться построить свою модель написанного кода,
этот человек быстро забывает и оперирует малым числом понятий.

именно из этого последовательно выросли:
1. разбиение кода на процедуры
2. запрет на goto
3. один оператор на строке
4. что код внутри блока должен быть сдвинуть относительно обрамляющего блока
5. отдельная часть кода должна влазить в монитор без необходимости скролинга
6. нет явным числам в коде, только через константы
7. названия длинные и по сути(черт! забыл правильный термин); нет - сокращениям и абревиатурам
7. разбиение кода на функции без side эффектов
8. разбиение кода на модули
9. разбиение кода на объекты/компоненты
10. запрет на static переменные
11. понятие "код - дурно пахнет"
12. появление метрики связность и метрики связанность
13. необходимость писать закрывающей фигурной скобки под открывающей
14. метрики на кол-во строк в метода, кол-во методов в объекте и т.д.
15. необходимость расстановки пробелов около знаков
16. необходимость разбиение метода на части

все это направленно на то, чтобы можно было двигаться следующим образом:
1. взять большой еще непонятный кусок
2. быстро выделить из него 3-7 подчастей
3. каждую подчасть разобрать отдельно(по этому же алгоритму) и сформировать свою упрощенную модель этой части.
4. из полученных моделей скомпоновать свою модель уже всей части -> т.е. получить понимание этой части

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

соответственно:
1. зачем нужно разбиение на методы? чтобы свою модель строить уже на основе готового опыта: какие атомарные операции над этим объектом есть/допустимы
2. зачем нужны четкое название и комментарии на модуль, объект, метод? чтобы можно было не лезть внутрь модуля, объекта, метода, а сразу сформировать свою модель этой сущности
3. почему комментарии внутри метода вредны?
а) это симптом о том, что сам по себе код пишется такой, что он не понятен читающему
b) текста становится больше, и он начинает вываливаться из головы.
  причем если код обычно формальный, и на основе его легко строить модели, то комментарии уже неформальные, и в них приходится вчитываться
4. зачем нужны пустые строки(разбиения на части) внутри метода? чтобы можно было при формировании понимания метода выполнить п.2(быстро выделить подчасти) на основе опыта автора
5. зачем нужны пробелы вокруг/после знаков внутри строки? чтобы строку можно было зрительно разбить на отдельные части, которые уже воспринимать по отдельности

Оценок нет

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Похожие записи

Powered by BlogEngine.NET 1.3.1.0
Theme by Mads Kristensen

Сергей Темных

Модулятор


Calendar

<<  Октябрь 2017  >>
повтсрчепясуво
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

View posts in large calendar

Страницы

    Последние комментарии

    Категории

    None


    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2017

    Sign in