Читайте также
72. Для уведомления об ошибках следует использовать исключения
РезюмеДля уведомления об ошибках лучше использовать механизм исключений, а не коды ошибок. Применять коды состояния (например, коды ошибок, переменную errno) следует только тогда, когда нельзя использовать
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами
Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск
1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей
В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на
1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы
Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных
11.1. Применение правила наименьшей неожиданности
Правило наименьшей неожиданности представляет собой общий принцип проектирования всех видов интерфейсов, а не только программных: "делайте наименее неожиданные вещи". Данное правило — следствие того факта, что человек
19.4. Почему следует использовать стандартную лицензию
Широко известные лицензии, которые согласуются с Определением открытого исходного кода (Open Source Definition), имеют твердо установившиеся "толковательные" традиции. Разработчики (и пользователи, в той мере, как это их
1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами
Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск
1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix
1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей
В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных
11.1. Применение правила наименьшей неожиданности
Правило наименьшей неожиданности представляет собой общий принцип проектирования всех видов интерфейсов, а не только программных: "делайте наименее неожиданные вещи". Данное правило — следствие того факта, что человек
19.4. Почему следует использовать стандартную лицензию
Широко известные лицензии, которые согласуются с Определением открытого исходного кода (Open Source Definition), имеют твердо установившиеся "толковательные" традиции. Разработчики (и пользователи, в той мере, как это их
Что следует повторно использовать?
Убедив себя в том, что Повторное использование - Это Хорошо, осталось выяснить, как же этого добиться?Первый возникающий вопрос - на каком уровне следует осуществлять повторное использование: персонала, спецификаций, проектов, их
Глава 25.
Когда не следует использовать ХР
Точные пределы использования ХР еще не до конца исследованы. Однако есть известный набор факторов, который делает применение ХР невозможным, – слишком большие команды, недоверчивые заказчики, технология, которая не позволяет