Правила программирования на С и С++. Главы 1-6 - Пропустите свой исходный тест через систему проверки орфографии

ОГЛАВЛЕНИЕ

• Правила программирования на С и С++. Главы 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 лучше, чем макрос
• Аргумент параметризированного макроса не должен появляться в правой части более одного раза
• Если все альтернативы отпали, то используйте препроцессор
• Все страницы