Главная
Попытка заменить пчелу
Предложения советских рационализаторов
Радиоэлектронные собеседники животных
Роботехника в производстве и в быту
Тайна профессора Рентгена
Деталь сама себя обрабатывает и охлаждает
Желтый подводный робот
Ледяные корабли
Открытия и наблюдения советских ученых
Новаторская перевозка грузов
Перпетуум мобиле с Алексеем Воробьёвым-Обуховым
Пишущая машинка стенографирует и расшифровывает
Шахматная махина маэстро кэмпелена
Роторно-винтовые ледоколы
Русскому керосину - 160 лет
Спасение в воздушных просторах
Что умеют машины
|
Главная - Литература Синтаксические ошибки Синтаксические ошибки ждет судьба мамонтов и саблезубых тигров. Диагностические модули компиляторов постоянно улучшаются, и времена, когда поиск неправильно расположенной точки с запятой иногда занимал несколько часов, почти ушли. Соблюдение следующих принципов поможет вам ускорить вымирание подобных ошибок. Не полагайтесь на номера строк в сообщениях компилятора Если компилятор сообщил о загадочной синтаксической ошибке, изучите фрагменты, расположенные прямо перед ошибкой и сразу после нее: возможно, компилятор неправильно понял проблему или просто включает плохой диагностический модуль. Обнаружив истинный дефект, попробуйте определить, почему компилятор указал не на ту команду. Понимание особенностей компилятора поможет находить дефекты в будущем. Не доверяйте сообщениям компилятора Компиляторы пытаются сообщить вам точную причину ошибки, но они сами нередко ошибаются, и, чтобы понять смысл их сообщений, иногда приходится читать между строк. Так, при целочисленном делении на О компилятор UNIX С может вывести сообщение «floating exception» (исключение при выполнении операции над числом с плавающей точкой). Используя Standard Template Library С++, можно получить пару сообщений об ошибке: первое - о действительной ошибке в использовании STL, а второе - «Еггог message too long for printer to print; message truncated» («Сообщение об ошибке сокращено, так как оно слишком велико для печати»). Наверное, вы и сами можете привести массу примеров неверных сообщений об ошибках. Не доверяйте второму сообщению компилятора Одни компиляторы находят множественные ошибки лучше, а другие хуже. Обнаружив первую ошибку, некоторые компиляторы приходят в такое возбуждение, что выдают десятки бессмысленных сообщений о других ошибках. Другим компиляторам, более рассудительным, тоже нравится находить ошибки, но они воздерживаются от вывода неверных сообщений. Если ваш компилятор сгенерировал ряд сообщений об ошибках и вы не можете быстро найти причину второго или третьего сообщения, не волнуйтесь - исправьте первую ошибку и перекомпилируйте программу Разделяй и властвуй Разделение программы на части особенно эффективно при поиске синтаксических ошибок. Если вы столкнулись с неуловимой синтаксической ошибкой, удалите часть кода и перекомпилируйте программу Ошибка или исчезнет (следовательно, она содержится в удаленном коде), или снова появится во всей своей красе (в этом случае удалите другую часть кода). Кроме того, вы можете получить другое сообщение об ошибке (это значит, что вы перехитрили компилятор и заставили его сгенерировать более разумное сообщение). {lepexpeitiiaii иыш Наличие Р ищите неверно размещенные комментарии редакторое с проверкой оинтак- " кавычки Многие текстовые редакторы для программи-сиса аавйсит от зрелости ере-* рования автоматически форматируют комментарии, стро-т программирования (см, раз- ковые литералы и другие синтаксические элементы. В бо- лее примитивных средах неправильное размещение символов комментария или кавычек может запутать компилятор. Для нахождения лишних символов комментария или кавычек в коде С, С++ или Java вставьте в него последовательность: Этот фрагмент завершит комментарий или строку, что поможет сузить область, в которой скрываются лишние символы. 23.3. Устранение дефекта Сложной частью отладки является поиск дефекта. Устранить его легко. Однако, как часто бывает, из-за этой самой легкости устранение одних дефектов создает благоприятные условия для внесения других. По крайней мере в одном исследовании было обнаружено, что первые варианты исправления дефектов в половине случаев оказывались некорректными (Yourdon, 198бЬ). Ниже я привел несколько советов по снижению вероятности ошибок этого рода. Прежде чем браться за решение проблемы, поймите ее «Руководство Дьявола по отладке» не врет: нет более эффективного способа усложнить себе жизнь и ухудшить качество программы, чем исправление дефектов без их настоящего понимания. Приступайте к устранению проблемы, только разобравшись в ней до конца. Триангулируйте источник ошибки с применением двух видов тестов: тех, что должны привести к ошибке, и тех, которые должны выполниться безошибочно. Выполняйте тесты, пока не поймете проблему достаточно хорошо, чтобы правильно предсказывать появление ошибки в каждом случае. Не ограничивайтесь пониманием проблемы - поймите программу Если вы понимаете контекст проблемы, у вас больше шансов решить ее полностью, а не частично. Исследование, проведенное с использованием короткой программы, показало, что программисты, стремящиеся полностью понять поведение программы, чаще изменяли ее правильно, чем программисты, концентрировавшиеся на локальном поведении и изучавшие программу только по мере надобности (Littman et al., 1986). Так как программа в этом исследовании была небольшой (280 строк), я не могу утверждать, что вам следует пытаться полностью понять программу из 50 ООО строк перед исправлением дефекта. Но вы должны понять хотя бы код, расположенный по соседству с дефектом - под «соседством» я понимаю не несколько, а несколько сотен строк. Подтвердите диагноз проблемы Перед исправлением дефекта убедитесь, что вы диагностировали проблему правильно. Выполните тесты, которые доказывают вашу гипотезу и опровергают конкурирующие гипотезы. Если вы установили только то, что ошибка может быть результатом одной из нескольких причин, к устранению проблемы приступать рано - исключите сначала другие причины. Расслабьтесь Один программист собирался в лыжный „ отлаживайте про-поход. Программа была почти готова к выпуску, он опазды- грамму стой, вал, и ему оставалось исправить только один дефект. Он из- Дж$ршд В$тб0рг менил исходный файл и зарегистрировал его в системе (йвтШ ШШгд) управления версиями. Он не выполнил перекомпиляцию программы и не проверил правильность изменения. А изменение оказалось неверным, что привело начальника программиста в ярость. Как можно изменять код приложения, готового к выпуску, не проверив его? Что может быть хуже? Разве это не верх некомпетентности? Если такой поступок и не является вершиной некомпетентности, он очень к ней близок, но это нисколько не сказывается на его распространенности. Решение проблемы второпях - один из самых неэффективных в плане времени подходов. Он подталкивает к необоснованным суждениям, неполной диагностике дефектов и внесению неполных исправлений. Принимая желаемое за действительное, вы можете увидеть решение там, где его нет. Давление - часто самовнушенное - склоняет к принятию случайных и непроверенных решений методом проб и ошибок. А вот другой подход. В самом конце разработки ОС Microsoft Windows 2000 одному из программистов нужно было исправить последний дефект, после чего уже можно было бы создать коммерческую версию. Он изменил код, проверил исправление и протестировал его на своей локальной сборке. Но сразу регистрировать исправление в системе управления версиями он не стал. Вместо этого он пошел играть в баскетбол, сказав: «Я сейчас чувствую слишком большое напряжение и поэтому не могу быть уверен в том, что рассмотрел все, что следовало. Часок отдохну, приведу мысли в порядок, а потом вернусь и зарегистрирую код, как только увижу, что мое исправление на самом деле корректно». Отдыхайте, пока правильность решения не станет очевидной. Не поддавайтесь соблазну сэкономить время: обычно это приводит к обратному результату. Следуя этим советам, вы всегда будете вносить правильные исправления, и руководителю не придется вызывать вас из лыжного похода. Пеикршная ссыпка Общие храняйте первоначальный исходный код Перед на-аойросы сеязанные с йамеме- чалом исправления дефекта обязательно заархивируйте шш кода, подробно обсужда- имеющийся код, чтобы в случае чего к нему можно было ются е шаве 24, вернуться. Имея дело с несколькими изменениями, вы мо- жете забыть, какое из них важно в текущий момент. Сохранение первоначального исходного кода позволит хотя бы сравнить старый и новый файлы и определить измененные фрагменты. Устраняйте проблему, а не ее симптомы Конечно, симптомы также нужно устранять, но главной целью должно быть устранение причин проблемы. До конца не разобравшись в проблеме, кода не исправить. Вы устраните симптомы и сделаете код еще хуже. Рассмотрим, например, фрагмент: Пример кода, требующего исправления (Java) for ( claimNumber = 0; claimNumber < numClaims[ client ]; claimNumber++ ) { sum[ client ] - sum[ client ] + claimAmount[ claimNumber ]; Предположим, величина sum для клиента 45 отличается от правильного значения на 3,45 доллара. Вот неверный способ решения этой проблемы: 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.0036 |