Прозрачность и воспринимаемость, подобно модульности, в основном являются свойствами конструкции, а не кода. Не достаточно получить правильные низкоуровневые элементы стиля, такие создание отступов в коде ясным и последовательным способом или использование хороших соглашений по именованию переменных. Данные качества гораздо сильнее связаны со свойствами кода, которые менее очевидны при просмотре. Ниже приводятся некоторые из них.

• Какова максимальная глубина иерархии вызова процедур? Т.е., не считая рекурсии, сколько уровней вызова человеку придется мысленно смоделировать, для того чтобы понять работу кода? Совет: будьте предельно внимательны, та как наличие более четырех уровней явно свидетельствует о возникшей проблеме.

• Имеются ли в коде инвариантные свойства [62] , строгие и видимые одновременно? Инвариантные свойства помогают человеку анализировать код и обнаруживать проблемные случаи.

• Являются ли вызовы функций в API-интерфейсах индивидуально ортогональными, или имеют ли они чрезмерное количество "магических" флагов и битов режима, которые заставляют один вызов выполнять несколько задач? Полный отказ от флагов режима может привести к созданию загроможденного API-интерфейса с чрезмерным количеством почти идентичных функций. Но еще шире распространена противоположная ошибка (множество флагов режима, которые легко забыть или перепутать).

• Существует ли несколько выступающих структур данных или одна глобальная таблица, собирающая высокоуровневые данные о состоянии системы? Просто ли визуализировать и проверить данное состояние, или оно рассеяно среди множества индивидуальных глобальных переменных или объектов, которые трудно найти?

• Существует ли в программе четкое, точное соответствие между структурами данных или классами и объектами реального мира, которые представлены ими?

• Просто ли отыскать часть кода, ответственную за любую заданную функцию? Как много внимания было уделено читабельности не только отдельных функций и модулей, но и кода в целом?

• Создает ли код частные случаи или избегает их? Каждый частный случай мог бы взаимодействовать со всеми остальными частными случаями, и все эти потенциальные коллизии являются ошибками, ожидающими своего часа. Но еще более важно то, что частные случаи усложняют понимание кода.

• Каково количество "магических" чисел (необъяснимых констант) в коде? Просто ли обнаружить ограничения реализации (такие как критические размеры буферов) путем просмотра?

Лучше всего, если код будет простым. Однако если проверка кода дает хорошие ответы на приведенные выше вопросы, то код может быть весьма сложным и вместе с тем не создавать невыполнимой когнитивной нагрузки на кураторов.

Читатели могут найти полезным сравнение данных вопросов с контрольным списком вопросов, касающихся модульности в главе 4.

Близким родственником присутствующей в среде программистов тенденции создавать чрезмерно сложные нагромождения абстракций является стремление чрезмерно оберегать остальных от низкоуровневых деталей. Несмотря на то, что скрывать такие детали в обычном режиме работы программы не является плохой практикой (например, в программе fetchmail ключ

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

Программы, не способные показать, что они выполняют, значительно усложняют поиск и устранение неисправностей. Поэтому опытные пользователи операционной системы Unix действительно воспринимают наличие отладочных ключей и оснащенность средствами контроля как хороший знак, а их отсутствие — как плохой. Отсутствие говорит о неопытности или небрежности разработчика. В то же время их наличие означает, что разработчик достаточно предусмотрителен, чтобы придерживаться правила прозрачности.

Соблазн чрезмерно скрывать детали особенно сильно проявляется в предназначенных для конечных пользователей GUI-приложениях, таких как программы чтения почты. Одной из причин, по которой Unix-разработчики прохладно воспринимают GUI-интерфейсы, является то, что поспешность проектировщиков таких интерфейсов в стремлении сделать их "дружественными к пользователю" часто делает их безнадежно закрытыми для любого, кто вынужден решать проблемы пользователей или должен взаимодействовать с интерфейсом за пределами узкого диапазона, предсказанного разработчиком пользовательского интерфейса.