Правила программирования на С и С++. Главы 1-6 - Тестовые подпрограммы не должны быть интерактивными
Written on .
ОГЛАВЛЕНИЕ
- Правила программирования на С и С++. Главы 1-6
- Глава 1. Процесс проектирования
- Сущность программирования: без сюрпризов, минимум сцепления и максимум согласованности
- Подавляйте демонов сложности (Часть 1)
- Решайте конкретную проблему, а не общий случай
- Интерфейс пользователя не должен быть похожим на компьютерную программу (принцип прозрачности)
- Не путайте легкость в изучении с легкостью в использовании
- Производительность может измеряться числом нажатий клавиш
- Если вы не можете сказать это по-английски, то вы не сможете выполнить это на С/С++
- Начинайте с комментариев
- Читайте код
- В цехе современных программистов нет места примадоннам
- Разлагайте сложные проблемы на задачи меньшего размера
- Используйте весь язык
- Проблема должна быть хорошо продумана перед тем, как она сможет быть решена
- Компьютерное программирование является индустрией обслуживания
- Вовлекайте пользователей в процесс проектирования
- Малое - это прекрасно. (Большое == медленное)
- Глава 2. Общие проблемы разработки программ
- Прежде всего, не навреди
- Нельзя измерять свою производительность числом строк
- Вы не можете программировать в изоляции
- Пустые потери времени
- Пишите программу с учетом сопровождения - вы специалист по сопровождению
- Глава 3. Форматирование и документация
- Программа без комментариев ничего не стоит
- Располагайте программу и документацию вместе
- Комментарии должны быть предложениями
- Пропустите свой исходный тест через систему проверки орфографии
- Комментарий не должен подтверждать очевидное
- Комментарий должен предоставлять только нужную для сопровождения информацию
- Комментарии должны быть в блоках
- Комментарии должны быть выровнены вертикально
- Используйте аккуратные столбцы везде, где можно
- Не располагайте комментариев между именем функции и открывающей скобкой
- Помечайте конец длинного составного оператора чем-нибудь, имеющим смысл
- Располагайте в строке только один оператор
- Указывайте имена аргументов в прототипах функций
- Используйте "предикатную" форму при разбиении длинных выражений
- Подпрограмма должна помещаться на экране
- Нужно обеспечивать возможность распечатки всего текста программы
- Используйте штриховую линию для зрительного разделения подпрограмм
- Пробел - один из наиболее эффективных комментариев
- Используйте отступы в четыре пробела
- Условные операторы выделяются абзацными отступами
- Комментарии должны иметь тот же отступ, что и окружающий текст программы
- Выравнивайте скобки вертикально по левой границе
- Используйте скобки, если в условном операторе имеется более, чем одна строка
- Глава 4. Имена и идентификаторы
- Имена должны быть обычными словами английского языка, описывающими то, что делает функция, аргумент или переменная
- Имена макросов должны записываться ЗАГЛАВНЫМИ_БУКВАМИ
- Избегайте области имен стандарта ANSI C
- Избегайте области имен Microsoft
- Избегайте ненужных идентификаторов
- Именованные константы для булевых величин редко необходимы
- Глава 5. Правила обычного программирования
- Не путайте привычность с читаемостью
- Функция должна делать только одно дело
- Иметь слишком много уровней абстракции или инкапсуляции так же плохо, как и слишком мало
- Функция должна вызываться более одного раза, но...
- Функция должна иметь лишь одну точку входа
- Избегайте дублирования усилий
- Не портьте область глобальных имен
- Помещайте более короткий блок условного оператора if/else первым
- Старайтесь сдвинуть ошибки с этапа выполнения на этап компиляции
- Применяйте указатели на функции С в качестве селекторов
- Избегайте циклов do/while
- В цикле со счетчиком его значение должно по возможности уменьшаться
- Не делайте одно и то же двумя способами одновременно
- Используйте оператор for, если имеются любые два из инициализурующего, условного или инкрементирующего выражений
- То, чего нет в условном выражении, не должно появляться и в других частях оператора for
- Допускайте, что ситуация может измениться в худшую сторону
- Компьютеры не знают математики
- Избегайте явно временных переменных
- Не нужно магических чисел
- Не делайте предположений о размерах
- Опасайтесь приведения типов (спорные вопросы С)
- Немедленно обрабатывайте особые случаи
- Не старайтесь порадовать lint
- Помещайте код, динамически распределяющий и освобождающий память, в одном и том же месте
- Динамическая память - дорогое удовольствие
- Тестовые подпрограммы не должны быть интерактивными
- Сообщение об ошибке должно подсказывать пользователю, как ее исправить
- Не выводите сообщения об ошибке, если она исправима
- Не используйте системно-зависимых функций для сообщений об ошибках
- Глава 6. Препроцессор
- Все из одного .h файла должно быть использовано в по меньшей мере двух .c файлах
- Используйте вложенные директивы #include
- Вы должны быть всегда способны заменить макрос функцией
- Операция ?: не то же самое, что и оператор if/else
- enum и const лучше, чем макрос
- Аргумент параметризированного макроса не должен появляться в правой части более одного раза
- Если все альтернативы отпали, то используйте препроцессор
- Все страницы
Страница 82 из 93
75. Тестовые подпрограммы не должны быть интерактивными.
Мне часто показывают тестовые программы, имеющие усовершенствованный интерактивный интерфейс пользователя. Это не только является пустой тратой времени, но и не может быть использовано для тщательного тестирования. Люди, сидящие за клавиатурами и пробующие все, что им приходит в голову, недостаточно методичны. Поэтому для систематического выполнения функций, подлежащих проверке, лучше использовать неинтерактивную тестовую функцию.
И, кстати, не удаляйте эту тестовую процедуру; просто используйте предложение #ifdef TEST для включения или выключения этой подпрограммы из компиляции. Если вы похожи на меня, то вы утром удалите эту тестовую функцию, а уже к обеду она вам понадобиться снова, даже если вы не пользовались ей последние два года.