Многие компании и отдельные девелоперы борются с так называемым “гавнокодом”. Борьба с тем самым кодом — это хорошо, но я заметил проблему, связанную с этим процессом.
Похоже, что у многих нет четких критериев, по которым можно было бы оценивать код на его качество. Одни утверждают, что если в каждом конкретном куске кода не использован какой-либо из существующих паттернов, то это уже некачественный код. Кто-то утверждает, что весь текст класса должен влазить на экран. Некоторые утверждают, что каждый блок if должен быть окружен {}, даже если он состоит из одной команды и т.д.
Как бы там ни было, но все, что было успешного и жизнеспособного изобретено в программировании — все является производным от одного основного принципа. И именно с точки зрения этого принципа нужно оценивать пригодность тех или иных методик написания кода.
Этот принцип Дейкстра называл принципом пострения интеллектуально управляемых программ или принципом постоения иерархических систем. Этот принцип неразрывно связан с человеческим
Дейкстра говорил о том, что человеку сложно воспринимать большой объем линейной информации. В то же время он утверждал, что иерархическая группировка той же самой информации значительно упрощает работу с этой информацией. И это становится очевидным, если знать, что человеческий
Исследования также показали, что среднестатистический человек может безошибочно анализировать объекты и их взаимодействие, количество которых не больше 7. При превышении этого количества наблюдается нелинейное увеличение количества ошибок, допускаемых человеком.
Применение принципа иерархических систем при создании дизайна языков программирования породило всем нам хорошо известное структурированное, затем объектно-ориентированное, а за ним и компонентное программирование.
Игнорирование этого же принципа приводит к ужасным, уродливым и глючным системам, которые никто не может удержать в голове и, как следствие, — понять и анализировать.
Игнорирование этого принципа в структурированном или даже объектно-ориентированном программировании ведет к ужасным программам, которые не может понять даже их автор. Отсутствие понимания собственного кода — 100% гарантия того, что программа не будет работать правильно.
Вторым важным моментом, который упускают из виду девелоперы при разработке и анализе кода — это непонимание того, чем, собственно, является программный код. Некоторые считают, что программный код — это исключительно инструкции для компьютера и у него нет больше никаких других функций. Но, если взять на вооружение такую точку зрения, то программы сегодня до сих пор писались бы в машинном коде и нам не нужны были бы громоздкие и понижающие эффективность сгенерированных программ трансляторы.
На самом деле, программный код является также средством упростить сложность машинного кода и записать свои мысли в форме, достаточно доступной для понимания и анализа другими девелоперами и самим же автором.
Поэтому, когда мы называем переменные, к примеру, sdlDlgs, motOmNs, m, a, b и тд, то мы этим усложняем понимание программы девелоперами. Еще хуже, когда переменным, методам, классам и т.д. даются имена, которые не соответствуют назначению(к примеру multiply для метода, выполняющего сложение и тд ).
Программа — это такое же средство создания моделей, упрощенно передающей отдельные аспекты реальности, как и математическая знаковая система. Представьте, как было бы сложно что-либо считать, если бы каждый обозначал такие простые операции, как +, -, *, / и т.д. своими уникальными символами. То же самое делает программист, когда дает неправильное имя программной единице. Это резко усложняет процесс анализа кода и, соответственно, резко увеличивает количество ошибок в программе.
Еще одну аналогию можно привести, сравнивая программы с человеческими языками. Конечно, программные знаковые системы намного примитивнее тех, что используют люди для обмена информацией между собой, но имеют ту же природу и связаны с человеческим иерархическим способом
Неправильному называнию идентификаторов в ЯП в человеческих языках соответствует подмена понятий. Это искажение реальности заставляет людей действовать неадекватно и казалось бы, нелогично(именно этим приемом пользуются политики и прочие мошенники). Так же и в ЯП, неправильные именования приводят к тому, что такой корявый код ведет к неправильному пониманию написанного и, соответственно, усложнению анализа на предмет наличие ошибок, а также усложнению модификации кода в будущем.
Для тех, кому хочется почитать более подробно об принципе создания интеллектуально управляемых программ, советую почитать в приатаченой доке статью Дейкстры “Смиренный программист”: khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd340.html
Статья по-психологии: www.psyworld.info/obem-i-raspredelenie-vnimaniya
Автор: JinnZest