| Оглавление |
1.
Правила программирования на С и С++. Главы 1-6
2.
Глава 1. Процесс проектирования
3.
Сущность программирования: без сюрпризов, минимум сцепления и максимум согласованности
4.
Подавляйте демонов сложности (Часть 1)
5.
Решайте конкретную проблему, а не общий случай
6.
Интерфейс пользователя не должен быть похожим на компьютерную программу (принцип прозрачности)
7.
Не путайте легкость в изучении с легкостью в использовании
8.
Производительность может измеряться числом нажатий клавиш
9.
Если вы не можете сказать это по-английски, то вы не сможете выполнить это на С/С
10.
Начинайте с комментариев
11.
Читайте код
12.
В цехе современных программистов нет места примадоннам
13.
Разлагайте сложные проблемы на задачи меньшего размера
14.
Используйте весь язык
15.
Проблема должна быть хорошо продумана перед тем, как она сможет быть решена
16.
Компьютерное программирование является индустрией обслуживания
17.
Вовлекайте пользователей в процесс проектирования
18.
Малое - это прекрасно. (Большое == медленное)
19.
Глава 2. Общие проблемы разработки программ
20.
Прежде всего, не навреди
21.
Нельзя измерять свою производительность числом строк
22.
Вы не можете программировать в изоляции
23.
Пустые потери времени
24.
Пишите программу с учетом сопровождения - вы специалист по сопровождению
25.
Глава 3. Форматирование и документация
26.
Программа без комментариев ничего не стоит
27.
Располагайте программу и документацию вместе
28.
Комментарии должны быть предложениями
29.
Пропустите свой исходный тест через систему проверки орфографии
30.
Комментарий не должен подтверждать очевидное
31.
Комментарий должен предоставлять только нужную для сопровождения информацию
32.
Комментарии должны быть в блоках
33.
Комментарии должны быть выровнены вертикально
34.
Используйте аккуратные столбцы везде, где можно
35.
Не располагайте комментариев между именем функции и открывающей скобкой
36.
Помечайте конец длинного составного оператора чем-нибудь, имеющим смысл
37.
Располагайте в строке только один оператор
38.
Указывайте имена аргументов в прототипах функций
39.
Используйте "предикатную" форму при разбиении длинных выражений
40.
Подпрограмма должна помещаться на экране
41.
Нужно обеспечивать возможность распечатки всего текста программы
42.
Используйте штриховую линию для зрительного разделения подпрограмм
43.
Пробел - один из наиболее эффективных комментариев
44.
Используйте отступы в четыре пробела
45.
Условные операторы выделяются абзацными отступами
46.
Комментарии должны иметь тот же отступ, что и окружающий текст программы
47.
Выравнивайте скобки вертикально по левой границе
48.
Используйте скобки, если в условном операторе имеется более, чем одна строка
49.
Глава 4. Имена и идентификаторы
50.
Имена должны быть обычными словами английского языка, описывающими то, что делает функция, аргумент или переменная
51.
Имена макросов должны записываться ЗАГЛАВНЫМИ_БУКВАМИ
52.
Избегайте области имен стандарта ANSI C
53.
Избегайте области имен Microsoft
54.
Избегайте ненужных идентификаторов
55.
Именованные константы для булевых величин редко необходимы
56.
Глава 5. Правила обычного программирования
57.
Не путайте привычность с читаемостью
58.
Функция должна делать только одно дело
59.
Иметь слишком много уровней абстракции или инкапсуляции так же плохо, как и слишком мало
60.
Функция должна вызываться более одного раза, но...
61.
Функция должна иметь лишь одну точку входа
62.
Избегайте дублирования усилий
63.
Не портьте область глобальных имен
64.
Помещайте более короткий блок условного оператора if/else первым
65.
Старайтесь сдвинуть ошибки с этапа выполнения на этап компиляции
66.
Применяйте указатели на функции С в качестве селекторов
67.
Избегайте циклов do/while
68.
В цикле со счетчиком его значение должно по возможности уменьшаться
69.
Не делайте одно и то же двумя способами одновременно
70.
Используйте оператор for, если имеются любые два из инициализурующего, условного или инкрементирующего выражений
71.
То, чего нет в условном выражении, не должно появляться и в других частях оператора for
72.
Допускайте, что ситуация может измениться в худшую сторону
73.
Компьютеры не знают математики
74.
Избегайте явно временных переменных
75.
Не нужно магических чисел
76.
Не делайте предположений о размерах
77.
Опасайтесь приведения типов (спорные вопросы С)
78.
Немедленно обрабатывайте особые случаи
79.
Не старайтесь порадовать lint
80.
Помещайте код, динамически распределяющий и освобождающий память, в одном и том же месте
81.
Динамическая память - дорогое удовольствие
82.
Тестовые подпрограммы не должны быть интерактивными
83.
Сообщение об ошибке должно подсказывать пользователю, как ее исправить
84.
Не выводите сообщения об ошибке, если она исправима
85.
Не используйте системно-зависимых функций для сообщений об ошибках
86.
Глава 6. Препроцессор
87.
Все из одного .h файла должно быть использовано в по меньшей мере двух .c файлах
88.
Используйте вложенные директивы #include
89.
Вы должны быть всегда способны заменить макрос функцией
90.
Операция ?: не то же самое, что и оператор if/else
91.
enum и const лучше, чем макрос
92.
Аргумент параметризированного макроса не должен появляться в правой части более одного раза
93.
Если все альтернативы отпали, то используйте препроцессор
| | |
Страница 1 из 93 Название этой книги отражает то, что я считаю основной трудностью при работе как с С++, так и с С: эти языки дают вам столько гибкости, что если у вас нет желания и способности призвать себя к порядку, то в итоге вы можете получить гигантский модуль не поддающейся сопровождению тарабарщины, притворяющейся к тому же компьютерной программой. Вы можете поистине делать все при помощи этих языков, даже если вы этого не хотите.
Ален И. Голуб Я профессионально занимаюсь программированием примерно с 1979 года и ежедневно пользуюсь правилами из этой книги. Я не утверждаю, что эти правила безусловны, или даже "верны". Однако я могу сказать, что они отлично мне служили все это время. Хотя эта книга не относится к категории путеводителей по "ловушкам и рытвинам", многие из этих правил предохранят вас от неприятностей того сорта, который обсуждается в путеводителях по "ловушкам и рытвинах". Практические правила по своей сути гибки. Они постепенно меняются с ростом опыта, и ни одно правило не действует постоянно. Тем не менее я предупреждаю вас с самого начала, что мое мнение относительно этого материла самое наилучшее и что я не очень симпатизирую неряшливым мыслям или небрежному программированию. Я не извиняюсь за усиленное подчеркивание тех вещей, в которые я сильно верю. Мои мнения всегда могут измениться, если, конечно, вы сможете убедить меня в том, что я не прав, но имейте в виду, что эта книга основана на опыте, а не на теории. Я сознаю, что большая часть этой книги подходит опасно близко к чьему-то культу и многие вещи, произносимые мной, дискуссионны, но думаю, что всегда имеется возможность разумного разговора двух людей, объединенных целью совершенствования своего мастерства. Я часто читаю курсы по С++ и объектно-ориентированному проектированию как по приглашению частных фирм, так и в Калифорнийском университете в Беркли. Эта книга появилась в ответ на просьбы моих студентов, большинство из которых увлеченные профессионалы с настоящим желанием изучить этот материал. Я вижу множество программ в процессе проверки домашних заданий, и эти программы достаточно репрезентативны в качестве произведений сообщества профессиональных программистов из района залива Сан-Франциско. К несчастью, каждый семестр я также вижу, что одни и те же проблемы повторяются снова и снова. Поэтому эта книга является некоторым образом и списком распространенных проблем, найденных мной в созданных настоящими программистами реальных программах, сопровождаемым моими советами по их решению. Обсуждаемые здесь проблемы программирования и проектирования не ограничиваются, к несчастью, лишь ученическими программами. Многие из примеров того, что не следует делать, взяты из коммерческого продукта: библиотеки классов Micrisoft Foundation Class(MFC) корпорации Micrisoft. Я могу сказать, что эта библиотека была спроектирована без заботы о хорошем сопровождении людьми, не подозревающими о существовании даже элементарных принципов объектно-ориентированного проектирования. Я не выделял явно большинство примеров этого в тексте, так как это не книга с названием "Что неправильно в MFC"; пользователи библиотеки MFC узнают ее код, когда натолкнутся на него. Я выбрал примеры из MFC просто потому, что мне пришлось много с ней работать и очень близко познакомиться с ее недостатками. Во многих других коммерческих библиотеках классов имеются сходные проблемы. Наконец, эта книга не является введением в С++. Обсуждение, сопровождающее относящиеся к С++ правила, предполагает, что вы знаете этот язык. Я не расходую место на описание того, как работает С++. Имеется множество хороших книг, которые учат вас языку С++, включая мою собственную C+C++ (New York, McGraw-Hill,1993). Вы должны также ознакомиться с принципами объектно-ориентированного проектирования. Я рекомендую второе издание книги Гради Буча Object-Oriented Analysis and Design with Applications (Redwood City, Benjamin Cummings,1994). О нумерации правил: иногда я группировал некоторые правила вместе, потому что удобно описывать их все одновременно. В этом случае все эти правила (имеющие различные номера) располагаются в начале раздела. Я использовал запись номера правила вида "1.2" в случаях, когда оно является особым случаем другого правила.
|