Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 [251] 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

Абсолютно другой подход к удобочитаемости можно найти в следующей книге.

Knuth, Donald Е. Literate Programming. Cambridge University Press, 2001. В этой подборке статей описывается концепция «грамотного программирования», объединяющего языки программирования и документирования. Кнут пишет о достоинствах грамотного программирования уже на протяжении 20 лет, но, хотя сам он может претендовать на титул Лучшего программиста планеты, грамотное программирование никак не войдет в моду. Прочтите примеры его кода, чтобы сформировать собственное мнение о причинах этой непопулярности.

Ключевые моменты

Главная цель визуального форматирования - это подчеркивание логической структуры кода. В критерии оценки достижения этой цели входят аккуратность, единообразие, удобство чтения и сопровождения кода.

Критерий хорошего внешнего вида имеет вторичное, далеко не основное значение. Однако если другие критерии соблюдены, а лежащий в основе код написан хорошо, то форматирование будет выглядеть привлекательно.

Visual Basic поддерживает явные блоки, а стандартное соглашение в Java предписывает их использование, поэтому, программируя на этих языках, вы можете применять явные блоки. В С++ хорошо смотрится эмуляция явных блоков или обозначение границ блоков с помощью пар begin-end.

Структурирование кода само по себе имеет большое значение. Конкретные соглашения менее важны, чем сам факт, что вы последовательно применяете определенные соглашения. Договоренности по форматированию, соблюдаемые лишь от случая к случаю, могут сильно ухудшить читаемость кода.

Многие аспекты форматирования сродни религиозным вопросам. Пытайтесь разделять объективные и субъективные предпочтения. Используйте явные критерии для обоснования вашей точки зрения при обсуждении стилевых предпочтений.



ГЛАВА 32

Самодокументирушщийся код

Содержание

32.1. Внешняя документация

32.2. Стиль программирования как вид документации

32.3. Комментировать или не комментировать?

32.4. Советы по эффективному комментированию

32.5. Методики комментирования

32.6. Стандарты ШЕЕ

Связанные темы

Форматирование: глава 31

Процесс программирования с псевдокодом: глава 9

Классы: глава 6

Высококачественные методы: глава 7

Программирование как общение: разделы 33.5 и 34.3

Пшите m шт ш того, wo стандарты документации разумны, большинству про-все программисты, которые бу-/(утоопроеождать аашу щтт-му. - склонные к шшчт пси* хогшты. знающие, щ ш живете.

Атнт

граммистов нравится писать документацию. Как и форматирование, хорошая документация - свидетельство профессиональной гордости, выражаемой программистом в программе. Документация имеет много вариантов, и после ее общего обзора в этой главе мы рассмотрим специфический вид документации, известный как «комментарии».

32.1. Внешняя документация

Документация программного проекта складывается из ин-дшументемий имеются сшдар- формации, содержащейся в листингах исходного кода, и ты (см. раадея 32.6), внешней информации, которая обычно имеет форму отдель-

ных документов или папок разработки блоков. В крупных



формальных проектах основная часть документации является внешней Qors, 1998). Внешняя документация этапа конструирования обычно относится к более высокому уровню, чем код, и к более низкому, чем документация этапов определения проблемы, выработки требований и проектирования архитектуры.

Папки разработки блоков Папка разработки блока yji,i>i0 001110 iiaii.

(unit-development folder, UDF), или папка разработки ПО как разработки бяоков см. в «The

(software-development folder, SDF), - это неформальный Unit Development Fofeler (UDF): An

документ, содержащий записи, используемые разработчи- Ofective ManagementTooi forSoft-

KOM BO время конструирования. Термин «блок» здесь не имеет Development* (Ingrassla, ШЩ и «ТЬе Unit Development Fol-

точпого определения: обычно под ним понимается класс, der {(jPF)-А Теп«Уеаг Perspective* а иногда - пакет или компонент. В первую очередь UDF (ingrassia, 1987). служит для регистрации решений проектирования, которые

нигде больше не документируются. Во многих проектах устанавливаются стандарты, определяющие минимальное содержание UDF - например, копии релевантных требований, высокоуровневые аспекты проектирования, реализуемые в блоке, копии стандартов разработки, листинги кода и заметки разработчика блока. Иногда заказчик требует, чтобы ему предоставлялись папки UDF; часто они предназначены только для внутреннего использования.

Документ детального проектирования Документ детального проектирования описывает низкоуровневую конструкцию. Он очерчивает решения, принятые при проектировании классов или методов, рассмотренные варианты и мотивы выбора окончательных подходов. Иногда эта информация включается в формальный документ; при этом детальное проектирование обычно рассматривается как этап, отдельный от конструирования. Иногда этот документ состоит преимущественно из заметок разработчиков, собранных в UDF, но чаще эта документация присутствует только в самом коде.

32.2. Стиль программирования как вид документации

В отличие от внешней внутренняя документация включается в сам код. Это наиболее подробный вид документации, относящийся к уровню команд исходного кода. Внутренняя документация сильнее всего связана с кодом, поэтому при изменении кода она чаще остается корректной, чем документация иных видов.

Главный вклад в документацию уровня кода вносится не комментариями, а хорошим стилем программирования. Грамотное структурирование программы, использование простых и понятных подходов, удачный выбор имен переменных и методов, использование именованных констант вместо литералов, ясное форматирование, минимизация сложности потока управления и структур данных - все это аспекты стиля программирования.

Вот пример плохого стиля программирования:



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 [251] 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.009