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

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. В этом случае для корректной компиляции пара begin и end необязательна, и вы можете выбрать один из трех вариантов стиля, показанных в листинге 31-31:

Листинг 31-31. Пример вариантов стиля для блоков из одного оператора (Java)

- Стиль 1

->if ( expression ) один-оператор;

- Стиль 2а

•-if ( expression ) { один-оператор;

- Стиль 26

>if ( expression ) {

один-оператор; }

- Стиль 3

>if ( expression ) один-оператор;

Существуют аргументы в защиту каждого из этих трех подходов. Стиль 1 следует схеме отступов, используемой для блоков, поэтому он согласуется с остальными подходами. Стиль 2 (как 2а, так и 26) также не противоречит общим правилам, а пары begin-end уменьшают вероятность добавления операторов после условия if не указав begin и end. Это станет особенно трудноуловимой ошибкой, потому что отступы будут подсказывать вам, что все в порядке, однако компилятор не интерпретирует отступы. Основное преимущества Стиля 3 над Стилем 2 в том, что его легче набирать. Его преимущество над стилем 1 в том, что при копировании в другую часть программы он с большей вероятностью будет скопирован правильно. А недостаток в том, что при использовании построчного отладчика такая строка будет рассматриваться как одно целое и вы не узнаете, выполняется ли выражение после проверки условия if

Я использовал Стиль 1 и много раз становился жертвой неправильной модификации. Мне не нравится нарушение стратегии отступов в Стиле 3, поэтому его я тоже избегаю. В групповых проектах я предпочитаю вариации Стиля 2 из-за получаемого единообразия и возможности безопасной модификации. Независимо от избранного стиля применяйте его последовательно и используйте один и тот же стиль в условиях и во всех циклах.

В сложных выражениях размещайте каждое условие на отдельной строке

Размещайте каждую часть сложного выражения на отдельной строке. Листинг 31-32 содержит пример выражения, форматированного без учета удобочитаемости:



Листинг 31-32. Пример совершенно неформатированного (и нечитаемого) сложного выражения (Java)

if (((О inChar) && (inChar <= 9)) ((а <= inChar) (inChar z)) ((A inChar) && (inChar <= Z)))

Это пример форматирования для машины, а не для человека. Разбив выражение на несколько строк, как показано в листинге 31-33, вы можете обеспечить более удобное чтение.

Листинг 31-33. Пример вполне читаемого сложного выражения (Java)

if ( ( ( О <= inChar ) && ( inChar <= 9 ) ) ( ( а <= inChar ) && ( inChar z ) ) ( ( A inChar ) && ( inChar Z ) ) )

Второй фрагмент использует несколько методов формати- цврехрешад «сшха Другая рования (отступы, пробелы, размещение значений в соот- методика оовышения удобочи- * ветствии с числовой прямой и выделение незавершенных таемости сложных еыраженйй строк) - в результате выражение вполне можно прочесть. - перенеш т в логические Более того, назначение проверки понятно. Если выражение Фуи* (<« РШ W), содержит небольшую ошибку, скажем, указана z вместо Z, то

при таком форматировании в отличие от менее аккуратного варианта это сразу бросится в глаза.

Избегайте операторов goto Первоначальная причина цервщйш есыш Об опера-отказа от goto состояла в том, что они затрудняли доказа- р gfQ щ рщц 73 тельство корректности программы. Это хороший аргумент

для тех, кто хочет доказать, что их программы корректны, т. е. практически ни для кого. Для большинства программистов более насущная проблема состоит в том, что операторы goto затрудняют форматирование кода. Делаете ли вы отступ в коде между 0/0 и меткой, на которую он переходит? Что, если у вас есть несколько о/о, использующих одну и ту же метку? Размещаете ли вы их один под другим? Вот несколько советов по форматированию goto.

Избегайте QOto. Это также позволит обойти проблемы

° Метки Го должны быть выров-

форматирования.

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

Помещайте оператор, содержащий goto, на отдельной * кредитной карты, строке. Это делает использование goto очевидным.

Помещайте метку перехода goto на отдельной строке.

Окружите ее пустыми строками. Это подчеркнет наличие метки. Строку, содержащую метку, выравнивайте по левому краю, чтобы сделать метку настолько очевидной, насколько это возможно.

Листинг 31-34 показывает эти соглашения по форматиро- ДешшЛт ванию goto в действии. „у см. подраадея «Обработка

ошибок и операторы до(о» раздела 17.3.



Листинг 31-34. Пример наилучшего выхода из плохой ситуации (использование goto) С++

void PurgeFiles( ErrorCode & errorCode ) { FileList fileList; int numPilesToPurge = 0;

MakePurgeFileList( fileList, numPilesToPurge );

errorCode = FileError Success; int filelndex = 0;

while ( filelndex < numPilesToPurge ) { DataPile fileToPurge;

if ( !PindPile( fileList[ filelndex ], fileToPurge ) ) { errorCode = FileError NotFound;

- Здесь используется goto.

goto END.PROC;

if ( !OpenPile( fileToPurge ) ) { errorCode = FileError NotOpen;

- Здесь используется goto.

-> goto END PROC;

if ( !OverwriteFile( fileToPurge ) ) { errorCode = FileError CantOverwrite;

- Здесь используется goto.

-> goto END PROC;

if ( !Erase( fileToPurge ) ) { errorCode = FileError CantErase;

Здесь используется goto.

L> goto END.PROC;

filelndex++;

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

1~>END PR0C:

DeletePurgeFileList( fileList, numPilesToPurge );



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