1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ
1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ
Известно, что люди плохо справляются с деталями. Соответственно, любой вид ручного создания программ является источником задержек и ошибок. Чем проще и более абстрактной может быть программная спецификация, тем более вероятно, что проектировщик реализует ее правильно. Сгенерированный код (на всех уровнях) почти всегда является более дешевым и более надежным, чем код, написанный вручную.
Общеизвестно, что это на самом деле так (в конце концов, именно поэтому созданы компиляторы и интерпретаторы), однако зачастую никто не задумывается о последствиях. Изобилующий повторениями код на языке высокого уровня, написание которого утомительно для людей, является такой же продуктивной целью для генератора кода, как машинный код. Использование генераторов кода оправдано, когда они могут повысить уровень абстракции, т.е. когда язык спецификации для генератора проще, чем сгенерированный код, и код впоследствии не потребует ручной доработки.
В традициях Unix генераторы кода интенсивно используются для автоматизации чреватой ошибками кропотливой работы. Классическими примерами генераторов кода являются грамматические (parser) и лексические (lexer) анализаторы. Более новые примеры — генераторы make-файлов и построители GUI-интерфейсов.
Данные методики рассматриваются в главе 9.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Как установить и запустить «Аську», если администратор заблокировал эту возможность
Как установить и запустить «Аську», если администратор заблокировал эту возможность Этот раздел касается не только ICQ, но и всех остальных программ тоже. Часто помимо запрета на посещение некоторых веб-узлов в компаниях существует ограничение на запуск программ. К
Пишите, Шура, пишите
Пишите, Шура, пишите Метки: темы блога, автор блога, маркетинг, пользовательский контентХороший маркетинг начинается с хорошего продукта. Блог компании – это тоже своего рода продукт, постоянно изменяемый автором. Складывается он из оформления, юзабилити и содержания.
5. Возможность создания нескольких инфопродуктов по одной теме
5. Возможность создания нескольких инфопродуктов по одной теме Далее возьмите свою тему, напишите и обведите ее на листе бумаги. Подумайте, можно ли в этой сфере делать не один продукт, а много, целую линейку. Ваша сфера представляет собой коллекцию нюансов – чтобы
Цикл создания программы
Цикл создания программы Независимо от используемых программных средств, процесс создания новой программы можно разбить на пять простых шагов.1. Проектирование.Здесь определяется, что должна делать программа, как она должна выглядеть на экране и взаимодействовать с
1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix
1.6.6. Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается
1.6.6. Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается Под "большими программами" в здесь подразумеваются программы с большим объемом кода и значительной внутренней сложностью. Разрешая
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить" Одно из старейших и наиболее постоянных правил проектирования в Unix гласит: если программа не может "сказать" что-либо интересное или необычное, то ей следует
Правило 28: Избегайте возвращения «дескрипторов» внутренних данных
Правило 28: Избегайте возвращения «дескрипторов» внутренних данных Представим, что вы работаете над приложением, имеющим дело с прямоугольниками. Каждый прямоугольник может быть представлен своим левым верхним углом и правым нижним. Чтобы объект Rectangle оставался
Правило 52: Если вы написали оператор new с размещением, напишите и соответствующий оператор delete
Правило 52: Если вы написали оператор new с размещением, напишите и соответствующий оператор delete Операторы new и delete с размещением встречаются в C++ не слишком часто, поэтому в том, что вы с ними не знакомы, нет ничего страшного. Вспомните (правила 16 и 17), что когда вы пишете такое
1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix
1.6.6 Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается
1.6.6 Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается Под "большими программами" в здесь подразумеваются программы с большим объемом кода и значительной внутренней сложностью. Разрешая
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"
1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить" Одно из старейших и наиболее постоянных правил проектирования в Unix гласит: если программа не может "сказать" что-либо интересное или необычное, то ей следует
1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ
1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ Известно, что люди плохо справляются с деталями. Соответственно, любой вид ручного создания программ является источником задержек и ошибок. Чем проще и
1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ
1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ При создании и развитии программного обеспечения (ПО) рекомендуется применять следующие общесистемные принципы:1) принцип включения, предусматривающий, что требования к созданию, функционированию и развитию ПО определяются
Реймонд Эрик Стивен
Просмотр ограничен
Смотрите доступные для ознакомления главы 👉