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

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

Пример использования операторов INhen-else вместо искусственной переменной для оператора case - хорошая практика (Java)

if ( UserCommancl.equals( COMMAND STRING COPY ) ) { CopyO;

else if ( UserCommand.equals( COMMAND STRING DELETE ) ) { DeleteCharacterO;

else if ( UserCommand.equals( COMMAND STRING FORMAT ) ) { Format();

else if ( UserCommand.equals( COMMAND STRING HELP ) ) { HelpO;

else {

HandleUserInputError( ErrorType InvalidCommandInput );

Используйте вариант no умолчанию только для обработки настоящих значений по умолчанию Порой, когда остается единственный вариант, вы решаете закодировать его как вариант по умолчанию. Заманчиво, но... неразумно: вы лишаетесь автоматического документирования, предоставляемого метками оператора case, и теряете возможность определения ошибок с помощью варианта по умолчанию.

Такие операторы case подвержены ошибкам при модификации. Если вы используете настоящее значение по умолчанию, то добавление нового варианта тривиально: вы просто дописываете новую метку и соответствующий код. Если же значение по умолчанию искусственно, провести изменения сложнее. Вам придется добавить новый вариант, возможно, сделав его новым умолчанием, а затем поменять прежний вариант по умолчанию так, чтобы он стал обычным вариантом. Поэтому изначально используйте только настоящие значения по умолчанию.

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

Пример использования варианта по умолчанию для выявления ошибок - хорошая практика (Java)

switch ( commandShortcutLetter ) { case a :

PrintAnnualReportO; break; case p:

Никаких действий не требуется, но этот вариант предусмотрен, break; case q :

PrintQuarterlyReportO; break;



case s:

PrintSummaryReport();

break; default:

DisplayInternalError( "Internal Error 905: Call customer support." );

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

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

В С++ и Java старайтесь не писать код, проваливающийся сквозь блоки оператора case С-подобные языки (С, С++ и Java) не выполняют выход из блока case автоматически. Вместо этого вы должны явно закодировать конец блока. Если этого не сделать, программа провалится сквозь этот блок и начнет выполнять следующий. Это иногда приводит к некоторым вопиющим способам программирования, включая следующий пример:

Пример неправильного использования оператора case (С++)

switch ( InputVar ) { case A : if ( test ) {

оператор 1 оператор 2 case В : оператор 3

оператор 4

break;

Этот способ плох, так как приводит к перемешиванию уп-

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

fipHMBp лучше, он есть на ляющих конструкциях довольно тяжело, а в перекрываю-

самомдш1а.0том,1са1сщшть, щихся - практически невозможно. Модификация вариан-

нШы хороший код вытшш тов к или fe будет посложнее хирургической операции на

хорошо, а плохой - плохо, см. головном мозге, и вполне вероятно, что их придется пол-

йоядраадея «Разметка тн\т г,

строТ» ращяа 31.3 и оставшу. ос1ъю переписать, чтобы получить работоспособную вер-

юся часть гшы 31. с- ™ i и можете сделать с самого начала. В общем,

лучше избегать сквозного перехода в блоках оператора case.



В С-- ясно и безошибочно обозначайте код, проваливающийся сквозь блоки оператора case Если вы намеренно написали код, который должен выполняться в нескольких блоках case подряд, внятно прокомментируйте место, где это происходит, и объясните, почему это должно быть закодировано таким способом:

Пример документирования сквозного выполнения блоков case (С++)

switch ( errorDocumentationLevel ) { case DocumentationLevel Full:

DisplayErrorDetails( errorNumber );

СКВОЗНОЙ ПЕРЕХОД - Полная документация также печатает суммарные комментарии.

case DocumentationLevel Summary:

DisplayErrorSummary( errorNumber );

СКВОЗНОЙ ПЕРЕХОД - Суммарная документация

также печатает номер ошибки.

case DocumentationLevel NumberOnly: DisplayErrorNumber( errorNumber ); break;

default:

DisplayInternalError( "Internal Error 905: Call customer support." );

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

---1

Контрольный список: использование условных операторов http; cc2e.coi!i/i545

Операторы if-then

□ Очевиден ли номинальный путь выполнения кода?

□ Правильно ли выполняется ветвление при проверке if-then на равенство?

□ Присутствует и задокументирован ли блок e/se?

□ Корректен ли блок else?

□ Правильно ли расположены блоки И и else - нет ли инверсии?

□ Следует ли нормальный вариант после /У, а не после else?

Последовательности if-then-else-if

□ Преобразуются ли сложные проверки в вызовы логических функций?

□ Проверяются ли наиболее вероятные случаи первыми?

□ Все ли варианты учитываются?

□ Является ли последовательность if-then-else-if лучшей реализацией или лучше использовать оператор case?



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