Правила программирования на С и С++. Главы 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 лучше, чем макрос
- Аргумент параметризированного макроса не должен появляться в правой части более одного раза
- Если все альтернативы отпали, то используйте препроцессор
- Все страницы
Страница 28 из 93
24. Комментарии должны быть предложениями.
Они должны быть хорошо составлены и иметь правильную пунктуацию, по возможности без сокращений. Не превращайте свои комментарии в секретный код, применяя странные сокращения и изобретая свой собственный грамматический строй. Вам также не должна требоваться нить Ариадны для расшифровки комментариев.