Книга



|
2. Подавляйте демонов сложности (Часть 1).
2. Подавляйте демонов сложности (Часть 1). Ричард Рашид (разработчик Mach - варианта ОС UNIX) выступил несколько лет назад с основным докладом на конференции разработчиков Microsoft. Его...
2.2. Решайте конкретную проблему, а не общий случай.
2.1. Не решайте проблем, которых не существует. 2.2. Решайте конкретную проблему, а не общий случай. Поучительно использовать OLE 2.0 как пример того, что случается с многими слишком сложными...
7.1. В цехе современных программистов нет места примадоннам.
7.1. В цехе современных программистов нет места примадоннам. Это следствие из правила чтения. Программисты, которые думают, что их код совершенен, которые отвергают критику, вместо того, чтобы...
8. Разлагайте сложные проблемы на задачи меньшего размера.
8. Разлагайте сложные проблемы на задачи меньшего размера. На самом деле это также правило и литературного стиля. Если концепцию слишком сложно объяснить за один раз, то разбейте ее на меньшие...
9.1. Используйте для работы соответствующий инструмент.
9. Используйте весь язык. 9.1. Используйте для работы соответствующий инструмент. Данное правило является спутником правила Не путайте привычность с читаемостью , представленного ниже, но...
10. Проблема должна быть хорошо продумана перед тем, как она сможет быть решена.
10. Проблема должна быть хорошо продумана перед тем, как она сможет быть решена. Это правило с двумя последующими первоначально располагалось в начале этой главы. Подумав, я переместил их сюда,...
11. Компьютерное программирование является индустрией обслуживания.
11. Компьютерное программирование является индустрией обслуживания. Меня иногда шокирует неуважение, проявляемое некоторыми программистами по отношению к пользователям своих программ, как если...
13. Заказчик всегда прав.
12. Вовлекайте пользователей в процесс проектирования. 13. Заказчик всегда прав. Ни одной программе не добиться успеха, если ее проектировщики не общаются непосредственно с ее конечными...
14. Малое - это прекрасно. (Большое == медленное)
14. Малое - это прекрасно. (Большое == медленное) Распухание программ является огромной проблемой. Жесткий диск вместимостью 350 Мбайт на моем лаптопе может вместить операционную систему,...
15. Прежде всего, не навреди.
15. Прежде всего, не навреди. Это правило касается сопровождения программ. Будучи ребенком, я читал научно-фантастический рассказ, в котором незадачливый путешественник во времени случайно...
18. Нельзя измерять свою производительность числом строк.
18. Нельзя измерять свою производительность числом строк. Прежде, когда вы изучали английский в школе, то вам никогда не приходило в голову сдавать черновик письменного задания, если вы,...
19. Вы не можете программировать в изоляции.
19. Вы не можете программировать в изоляции. Классическая книга Джеральда Уэйнберга The Psychology of Computer Programming (New York, Van Nostrand Reinhold, 1971) содержит великолепную историю...
20. Пустые потери времени.
20. Пустые потери времени. Если вы не можете решить неподатливую проблему, то займитесь на некоторое время чем-либо другим. Программисты часто наиболее продуктивны, когда смотрят в окно,...
21. Пишите программу с учетом сопровождения - вы специалист по сопровождению.
21. Пишите программу с учетом сопровождения - вы специалист по сопровождению. Сопровождение начинается немедленно после завершения программы, а сопровождением на этой стадии обычно занимаетесь...
21.1. Эффективность часто просто пугало.
21.1. Эффективность часто просто пугало. Я потратил несколько часов, делая одну подпрограмму более эффективной , и не останавливался, чтобы подумать о том, как часто эта подпрограмма будет...
22. Программа без комментариев ничего не стоит.
22. Программа без комментариев ничего не стоит. Программа, на написание которой затрачен год, может использоваться в течение 10 лет. Вам придется затратить на сопровождение гораздо больше...
23. Располагайте программу и документацию вместе.
23. Располагайте программу и документацию вместе. Если документация отделена от текста программы, то ее очень трудно обновлять. Следовательно, основная часть вашей документации должна...
24. Комментарии должны быть предложениями.
24. Комментарии должны быть предложениями. Они должны быть хорошо составлены и иметь правильную пунктуацию, по возможности без сокращений. Не превращайте свои комментарии в секретный код,...
25. Пропустите свой исходный тест через систему проверки орфографии.
25. Пропустите свой исходный тест через систему проверки орфографии. Ваши комментарии не только станут более читаемыми, этот метод побудит вас использовать в качестве имен переменных тех,...
26. Комментарий не должен подтверждать очевидное.
26. Комментарий не должен подтверждать очевидное. Начинающие программировать на С склонны попадать в эту ловушку. Избегайте явно нелепых случаев типа: ++x; // увеличить x но мне также не...
27. Комментарий должен предоставлять только нужную для сопровождения информацию.
27. Комментарий должен предоставлять только нужную для сопровождения информацию. Особенно неприятным и бесполезным комментарием является декларативный заголовочный блок. Заголовок сам по себе...
28. Комментарии должны быть в блоках.
28. Комментарии должны быть в блоках. Комментарии в общем воспринимаются лучше, когда помещаются в многострочных блоках, которые чередуются с блоками текста программы. Для этого комментарий...
29. Комментарии должны быть выровнены вертикально.
29. Комментарии должны быть выровнены вертикально. Выравнивайте начало и конец комментария вертикально в многострочных комментариях. /* Первая строка, * вторая строка, * третья строка. */ Если...
30. Используйте аккуратные столбцы везде, где можно.
30. Используйте аккуратные столбцы везде, где можно. Так как форматирование по сути является видом комментирования, то это правило применяйте также и к тексту программы. Два следующих блока...
31. Не располагайте комментариев между именем функции и открывающей скобкой.
31. Не располагайте комментариев между именем функции и открывающей скобкой. Основная сложность в следующем примере: foo( int x ) /* Не помещайте * комментарий */ здесь. { //... } заключается в...
32. Помечайте конец длинного составного оператора чем-нибудь, имеющим смысл.
32. Помечайте конец длинного составного оператора чем-нибудь, имеющим смысл. Прежде всего, подобные комментарии в конце блока: while ( a < b ) { for ( i = 10; --1 >= 0; ) { f( i ); } //...
33. Располагайте в строке только один оператор.
33. Располагайте в строке только один оператор. Нет абсолютно никакой причины упаковывать в одну строку столько операторов, сколько сможете, если у вас нет намерения сделать программу...
34. Указывайте имена аргументов в прототипах функций.
34. Указывайте имена аргументов в прототипах функций. Это особенно важно в определениях классов. Страницы руководств (и встроенных систем помощи) для программы, над которой вы старательно...
35. Используйте "предикатную" форму при разбиении длинных выражений.
35. Используйте предикатную форму при разбиении длинных выражений. Предикатом в английском языке называется вторая половина предложения - глагол и дополнение, над которым глагол выполняет...
36. Подпрограмма должна помещаться на экране.
36. Подпрограмма должна помещаться на экране. Затраты на вызов подпрограмм в С/С++ невелики; если для функции указано ключевое слово inline, то затрат фактически нет. Поэтому хорошая мысль...
37. Нужно обеспечивать возможность распечатки всего текста программы.
37. Нужно обеспечивать возможность распечатки всего текста программы. Часто проще найти ошибку на распечатанной странице, чем на экране, даже на большом. Текст на бумаге легче читается...
38. Используйте штриховую линию для зрительного разделения подпрограмм.
38. Используйте штриховую линию для зрительного разделения подпрограмм. Я всегда ставлю такой комментарий: //--------------------------------------------------------- над каждым определением...
39. Пробел - один из наиболее эффективных комментариев.
39. Пробел - один из наиболее эффективных комментариев. Это кажется мелочью, но это может чрезвычайно улучшить читаемость вашей программы. Обратите внимание, как используются пробелы в этой...
40. Используйте отступы в четыре пробела.
40. Используйте отступы в четыре пробела. Никлас Вирт, который изобрел языки Паскаль и Модула-2, однажды выпустил книгу, где всюду использовались отступы в один символ. Чтение листингов из нее...
41. Условные операторы выделяются абзацными отступами.
41. Условные операторы выделяются абзацными отступами. Я делаю это даже в операторах из одной строки: if ( by_land ) one(); else two(); а не так: if ( by_land ) one() else two(); Очевидным...
41.1. Комментарии должны иметь тот же отступ, что и окружающий текст программы.
41.1. Комментарии должны иметь тот же отступ, что и окружающий текст программы. Абзацные отступы предназначены для того, чтобы сделать структуру вашей программы легко понятной. Если вы...
42. Выравнивайте скобки вертикально по левой границе.
42. Выравнивайте скобки вертикально по левой границе. Иногда поиск отсутствующей фигурной скобки превращается в крупную проблему. Если вы вынесете скобки туда, где их хорошо видно, то их...
43. Используйте скобки, если в условном операторе имеется более, чем одна строка.
43. Используйте скобки, если в условном операторе имеется более, чем одна строка. Это правило применяется, если даже дополнительными строками является комментарий. Проблема заключается в том,...
44. Имена должны быть обычными словами английского языка, описывающими то, что делает функция, аргумент или переменная.
44. Имена должны быть обычными словами английского языка, описывающими то, что делает функция, аргумент или переменная. Избегайте аббревиатур; они ухудшают читабельность программ. Некоторые по...
44.1. Не используйте в качестве имен тарабарщину.
44.1. Не используйте в качестве имен тарабарщину. Отличный образец такого подхода можно наблюдать в любом предлагаемом Microsoft примере программы, хотя эта проблема ни в коем случае не...
45. Имена макросов должны записываться ЗАГЛАВНЫМИ_БУКВАМИ.
45. Имена макросов должны записываться ЗАГЛАВНЫМИ_БУКВАМИ. Как показывается в последующих разделах, макросы часто вызывают побочные эффекты. Поэтому полезно иметь возможность определить с...
45.1. Не используйте заглавных букв для констант перечисления.
45.1. Не используйте заглавных букв для констант перечисления. Должна быть обеспечена возможность замены констант, определенных в перечислении, на переменную типа const. Если ее имя записано...
45.2. Не используйте заглавных букв в именах типов, созданных при помощи typedef.
45.2. Не используйте заглавных букв в именах типов, созданных при помощи typedef. Так как макрос также может использоваться в манере, подобной typedef, то полезно знать может или нет что-то...
46. Избегайте области имен стандарта ANSI C.
46. Избегайте области имен стандарта ANSI C. Идентификаторы, начинающиеся с символа подчеркивания, и имена типов, оканчивающиеся на _t, были зарезервированы стандартом ANSI C для использования...
47. Избегайте области имен Microsoft.
47. Избегайте области имен Microsoft. Это может показаться правилом, специфичным только для Microsoft, но на самом деле это не так (учитывая имеющуюся склонность Microsoft к мировому...
48. Избегайте ненужных идентификаторов.
48. Избегайте ненужных идентификаторов. Имена для констант часто вообще не нужны. Например, не определяйте значения, возвращаемые при ошибке; если возвращается всего одна ошибка, возвратите...
49. Именованные константы для булевых величин редко необходимы.
49. Именованные константы для булевых величин редко необходимы. Выбор неверного имени может добавить значительную ненужную сложность в вашу программу. Рассмотрим следующую простейшую функцию,...
50. Не путайте привычность с читаемостью.
50. Не путайте привычность с читаемостью. (Или синдром настоящего программиста, который может программировать на любом языке как на ФОРТРАНе ). Многие люди пытаются злоупотреблять...
51. Функция должна делать только одно дело.
51. Функция должна делать только одно дело. Это обычно не очень удачная мысль - записывать то, что должна делать функция, через ее аргументы. Это должно делать имя функции. Например:...
52. Иметь слишком много уровней абстракции или инкапсуляции так же плохо, как и слишком мало.
52. Иметь слишком много уровней абстракции или инкапсуляции так же плохо, как и слишком мало. Основной смысл использования таких абстракций, как функции или символьные константы (или...