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

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

Эти код и комментарий новые и являются результатом развертывания оператора if.

else {

Не можем ничего делать, так как процедура сама занимается обработкой ошибки.

Это тоже новый код и комментарий.

else {

Не можем ничего делать, так как процедура сама занимается обработкой ошибки.

/У Если код ошибки некорректен, извещаем пользователя об обнаружении внутренней ошибки, else {

DisplayInteractiveMessage(

"Internal Error: Invalid error code in ReportErrorMessage()"

Вернуть статус.

return errorMessageStatus;

К каж;ому комментарию добавлена одна или несколько строк кода. Каждый блок кода выражает некоторое намерение, описанное комментариями. Все переменные объявлены и определены рядом с местом их первого использования. Каждый комментарий обычно разворачивается в 2-10 строк кода.

Теперь вернемся к спецификации и псевдокоду. Первоначальная спецификация из пяти предложений превратилась в 15 строк псевдокода, которые в свою очередь развернуты в метод размером в страницу. Хотя спецификация и была достаточно подробной, создание метода потребовало проектировочных работ при написании псевдокода и кодировании. Это низкоуровневое проектирование и есть одна из причин, по которой «кодирование» является нетривиальной задачей.

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

Преобразуйте код, соответствующий комментарию, в но-

п&рекрбстная ссылка и рвфак-

торинге см главу 24 метод. Дайте методу имя и напишите код вызова этого

метода. Если вы правильно применяли ППП, имя метода вы легко придумаете на основе псевдокода. Закончив работу с изначальным ко-/ом, переходите к вновь созданным методам и применяйте ППП к ним. Применяйте ППП рекурсивно. Вместо того чтобы писать несколько десятков строк кода для одной строки псевдокода, разбейте эту строку псевдокода на несколько предложений и для каждой из них напишите код.



Проверка кода

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

Ошибка может не проявиться до окончательного кодирова- перекреешя есыяха О поиске ния по нескольким причинам. Ошибка в псевдокоде может ошибок при построении архи-стать заметнее при детальной реализации. Конструкция, тектуры и выработке требований выглядящая элегантно в псевдокоде, на языке программиро- главу 3. вания может стать топорной. Проработка детальной реализации может выявить ошибку архитектуры, проекта или требований. Наконец, код может содержать самые банальные ошибки программирования - никто не совершенен! По всем этим причинам пересмотрите код, прежде чем двигаться дальше.

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

Одно из основных различий между любителями и профессиональными программистами - различие, появляющееся при переходе от суеверия к пониманию. Под суеверием здесь я понимаю не иллюзию, что программа выдает больше ошибок в полнолуние, а замену «прочувствования» программы ее пониманием. Если вы часто обнаруживаете, что подозреваете компилятор или аппаратные средства в ошибке, вы в плену суеверий. Давнишние исследования показали, что только около 5% всех ошибок связано с аппаратурой, компиляторами или ОС (Ostrand and Weyuker, 1984). Сейчас этот процент, видимо, еще меньше. Программист, достигший сферы понимания, обращает внимание прежде всего на свое творение, являющееся потенциальным источником 95% ошибок. Нужно знать роль каждой строки своей программы. Ничто не может называться верным только потому, что выглядит работоспособным. Если вы не знаете, почему это работает, вероятно, оно и не работает на самом деле.

Итог: работающий метод - это еще не все. Если вы не знаете, как он работает, изучайте его, обсуждайте его, экспериментируйте с альтернативными вариантами, пока не добьетесь понимания.

Компиляция метода Проверив метод, скомпилируйте его. Может показаться неэффективным так долго откладывать компиляцию. Вероятно, вы уменьшите себе работу, скомпилировав метод ранее и позволив компилятору проверить необъявленные переменные, обнаружить конфликты имен и т. д.

Между тем, отложив трансляцию на более поздний срок, вы получите ряд преимуществ. Основная причина в том, что, когда вы компилируете новый код, в вас начинают тикать внутренние часики. После первой трансляции появляется мысль: «Еще всего одна компиляция, и дело сделано». Этот синдром «еще всего одной компиляции» подвигает вас к скороспелым, чреватым ошибками изменениям, которые в долгосрочном плане увеличивают общее время работы. Не спешите и не компилируйте программу, пока не будете уверены, что она верна.



Вот несколько советов по эффективной компиляции.

Установите наивысший уровень предупреждений компилятора. Вы можете отловить изрядное число ошибок, лишь позволив компилятору их обнаруживать.

Применяйте проверяющие средства. Встроенные проверяющие средства компиляторов могут быть дополнены внешними, такими как lint для С. Даже не-компилируемый код, скажем, HTML и JavaScript, можно проверить соответствующими утилитами.

Выясните причину всех сообщений об ошибках и предупреждений. Подумайте, что сообщение говорит о вашем коде. Многие предупреждения зачастую указывают на низкое качество кода, и вам следует попытаться понять смысл каждого предупреждения. На практике предупреждения, которые вы видите раз за разом, вызывают одну из двух реакций: вы или не обращаете на них внимания, и они скрывают от вашего взгляда более важные предупреждения, или они попросту вас раздражают. Как правило, проще и безболезненней переписать код, решив проблему, вызывающую предупреждения, и, таким образом, избавиться от них.

Псекрешаи ттш Пода- Пройдите по коду отладчиком Скомпилировав метод, ностк т. в mm 22 и вдраз- запустите его в отладчике и пройдите по каждой строке кода.

*Создан11е mm дпя тес* Убедитесь, что каждая строка выполняется так, как вы ожи-тйроаанйя отдеяьнш кпассоа» даете. Следуя этому простому совету, вы сможете найти мно-тпш 22.5. ошибок.

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

шшя Подроб- Уи ошибки из метода Обнаруженные ошибки шш см. в шт 23, нужно удалить. Если к этому моменту ваш метод работает

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

Наведение глянца

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

Проверьте интерфейс метода. Убедитесь, что применяются все входные и выходные данные и используются все параметры (см. раздел 7.5).



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.0024