6. Главное — корректность, простота и ясность
6. Главное — корректность, простота и ясность
Резюме
Корректность лучше быстроты. Простота лучше сложности. Ясность лучше хитроумия. Безопасность лучше ненадежности (см. рекомендации 83 и 99).
Обсуждение
Сложно преувеличить значение простоты проектирования и ясности кода. Люди, которые будут сопровождать ваш код, скажут вам только спасибо за то, что вы сделали ваш код понятным. Кстати, зачастую это будете вы сами — когда будете вспоминать, о чем это вы думали полгода назад и как же работает этот код, который вы тогда написали... Прислушайтесь к следующим словам.
Программа должна быть написана для человека, который будет ее читать, и только попутно — для машины, которая будет ее выполнять.
— Гарольд Абельсон (Harold Abelson) и Джеральд Сассман (Gerald Jay Sussman)
Пишите программы в первую очередь для людей, и только потом для машин.
— Стив Мак-Коннелл (Steve McConnell)
Самые дешевые, быстрые и надежные компоненты вычислительной системы — те, которых в ней нет.
— Гордон Белл (Gordon Bell)
Эти отсутствующие компоненты также наиболее точны (они никогда не ошибаются), наиболее надежны (никогда не ломаются) и наиболее просты в разработке, документировании, тестировании и сопровождении. Важность простоты дизайна невозможно переоценить.
— Ион Бентли (Jon Bentley)
Многие из рекомендаций этой книги естественным образом приводят к легко изменяемому дизайну и коду, а ясность является наиболее желанным качеством для программы, которую легко сопровождать. То, что вы не в состоянии понять, вы не сможете уверенно и надежно переделать.
Вероятно, наиболее распространенным соперничеством в данной области является соперничество между ясностью кода и его оптимизацией (см. рекомендации 7, 8 и 9). Когда — не если — вы находитесь перед соблазном преждевременной оптимизации для повышения производительности и, таким образом, пессимизации для повышения ясности, — вспомните, что говорит рекомендация 8: гораздо проще сделать корректную программу быстрой, чем быструю — корректной. Избегайте "темных закутков" языка. Используйте простейшие из эффективных методов.
Примеры
Пример 1. Избегайте неуместной и/или чересчур хитроумной перегрузки операторов. В одной библиотеке пользовательского графического интерфейса пользователей без нужды заставляют писать w+c; для того, чтобы добавить в окно w дочерний управляющий элемент с (см. рекомендацию 26).
Пример 2. В качестве параметров конструктора лучше использовать именованные, а не временные переменные. Это позволит избежать возможных неоднозначностей объявлений, а также зачастую проясняет назначение вашего кода и тем самым упрощает его сопровождение. Кроме того, часто это просто безопаснее (см. рекомендации 13 и 31).
Ссылки
[Abelson96] • [Bentley00] §4 • [Cargill92] pp. 91-93 • [Cline99] §3.05-06 • [Constantine95] §29 • [Keffer95] p. 17 • [Lakos96] §9.1, §10.2.4 • [McConnell93] • [Meyers01] §47 • [Stroustrup00] §1.7, §2.1, §6.2.3, §23.4.2, §23.4.3.2 • [Sutter00] §40-41, §46 • [Sutter04] §29
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Простота и трудоемкость
Простота и трудоемкость Механизм прямого обмена сообщениями крайне просто выражается в программном коде. Когда достигнута полная ясность в значениях адресных параметров обмена, необходимо всего лишь несколько операторов, чтобы заставить все это «крутиться».Со стороны
Простота в использовании
Простота в использовании После правильной установки и настройки пользоваться системой VoIP-телефонии не сложнее, чем обычным телефоном. Принцип все тот же: вы снимаете трубку, ждете гудка, набираете номер, а когда собеседник отвечает, начинаете разговор. Конечно, если
§ 147. Простота ≠ примитивность
§ 147. Простота ? примитивность 5 марта 2008Фасад с карнизом на крыше всегда смотрится в сто раз лучше, домашнее, милее, роднее, приятнее и человечнее, чем фасад без ничего. Непонятно, почему это неочевидно современным архитекторам. Это же верно и по отношению к любому другому
Вносим ясность
Вносим ясность У начинающих разработчиков часто возникает путаница в голове от многочисленных опций, определяющих поведение InterBase с русскими буквами. Вероятно, дочитав до этого места, вы уже достаточно запутались во множестве взаимнопересекающихся определений. Чтобы
1.6.2. Правило ясности: ясность лучше, чем мастерство
1.6.2. Правило ясности: ясность лучше, чем мастерство Поскольку обслуживание является важным и дорогостоящим, следует писать такие программы, как если бы обмен наиболее важной информацией, осуществляемый программой, был связан не с компьютером, выполняющим данную
1.6.2. Правило ясности: ясность лучше, чем мастерство
1.6.2. Правило ясности: ясность лучше, чем мастерство Поскольку обслуживание является важным и дорогостоящим, следует писать такие программы, как если бы обмен наиболее важной информацией, осуществляемый программой, был связан не с компьютером, выполняющим данную
А.2.6.2 Простота внедрения (Installability)
А.2.6.2 Простота внедрения (Installability) Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для внедрения программного обеспечения в конкретное
Корректность (Correctness)
Корректность (Correctness) Определение: корректностьКорректность - это способность ПО выполнять точные задачи так, как они определены их спецификацией.Корректность является важнейшим качеством. Если система не делает того, что она должна делать, то все остальное - ее
Простота использования (Easy of Use)
Простота использования (Easy of Use) Определение: простота использованияПростота использования - это легкость, с которой люди с различными знаниями и квалификацией могут научиться использовать ПО и применять его для решения задач. Сюда также относится простота установки,
Корректность класса
Корректность класса Вооруженные понятиями инварианта, предусловий и постусловий, мы можем теперь точно определить понятие корректности уже не отдельной подпрограммы, а класса в целом.Класс, подобно всем остальным программным элементам, не может быть корректным или
Корректность предложения rescue
Корректность предложения rescue Формальное определение корректности класса выдвигает два требования к компонентам класса. Первое (1) требует, чтобы процедуры создания гарантировали корректную инициализацию - выполнение инварианта класса. Второе (2) напрямую относится к
Корректность систем и классов
Корректность систем и классов Для обсуждения проблем ковариантности и скрытия потомком нам понадобится несколько новых терминов. Будем называть классово-корректной (class-valid) систему, удовлетворяющую трем правилам описания типов, приведенным в начале лекции. Напомним их:
Корректность систем: первое приближение
Корректность систем: первое приближение Давайте сконцентрируемся вначале на проблеме ковариантности, более важной из двух рассматриваемых. Этой теме посвящена обширная литература, предлагающая ряд разнообразных