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

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

который гарантированно будет первым в сортированном списке. */ int lowerBoundary = clata[ firstElement-1 ]; clata[ firstElement-1 ] = SORT MIN;

/* Элементы в позициях от firstElement до sortBoundary-1 всегда отсортированы. При каждом проходе цикла sortBoundary увеличивается, и элемент, соответствующий новому каждом проходе цикла sortBoundary увеличивается, и элемент, соответствующий новому sortBoundary, возможно, будет неправильно отсортирован, поэтому он вставляется в надлежащую позицию массива между firstElement и sortBoundary. */ for (

int sortBoundary = firstElement+1 ; sortBoundary <= lastElement; sortBoundary++ ) {

int insertVal = data[ sortBoundary ];

int insertPos = sortBoundary;

while ( insertVal < data[ insertPos-1 ] ) {

data[ insertPos ] = data[ insertPos-1 ];

insertPos = insertPos-1;

data[ insertPos ] = insertVal; }

/* Возвращаем исходное значение элементу, расположенному на нижней границе интервала

data[ firstElement-1 ] = lowerBoundary; }

Это тот же код, что и в листинге 31-1. Хотя большинство согласится, что такое форматирование кода гораздо лучше первого примера, но код все еще не слишком читабелен. Текст еще расположен слишком кучно и не содержит подсказок о логической организации метода. Такое форматирование соответствует О на шкале вариантов форматирования. Первый пример был несколько надуман, но второй не так уж редко встречается в жизни. Я видел программы, состоящие из нескольких тысяч строк кода, форматированные столь же плохо, как и здесь. А при отсутствии документации и плохих именах переменных общая читабельность была еще хуже, чем в этом примере. Этот код отформатирован для компьютера, и нет никаких свидетельств, что автор думал о людях, которые будут читать его код. Листинг 31-3 содержит усовершенствованный вариант.

Листинг 31-3. Пример № 3 форматирования кода (Java)

/* Используем способ сортировки методом вставок для сортировки массива «data» в возрастающем порядке. Этот метод предполагает, что [ firstElement ] не является первым элементом данных и элемент data[ firstElement-1 ] достижим.

public void InsertionSort( int[] data, int firstElement, int lastElement ) { Заменяем элемент, расположенный на нижней границе интервала, элементом, который гарантированно будет первым в отсортированном списке, int lowerBoundary = data[ firstElement-1 ]; data[ firstElement-1 ] = SORT MIN;



/* Элементы в позициях от firstElement до sortBoundary-1 всегда отсортированы.

При каждом проходе цикла sortBoundary увеличивается,

и элемент, соответствующий новому sortBoundary,

возможно, будет неправильно отсортирован,

поэтому он вставляется в надлежащую позицию массива

где-то между firstElement и sortBoundary.

for ( int sortBoundary = firstElement + 1; sortBoundary <= lastElement; sortBoundary++ ) {

int insertVal = data[ sortBoundary ];

int insertPos = sortBoundary;

while ( insertVal < data[ insertPos - 1 ] ) {

data[ insertPos ] = data[ insertPos - 1 ];

insertPos - insertPos - 1;

data[ insertPos ] = insertVal;

Возвращаем исходное значение элементу,

расположенному на нижней границе интервала

data[ firstElement - 1 ] = lowerBoundary;

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

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

Основная теорема форматирования

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

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



Интерпретация программы человеком и компьютером

Любой дурак тшу нашсать Форматирование - это ключ к структуре программы. Ком-

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

рошие программисты пшут операторах begin и end, а читатель-человек склонен делать

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

Шртии Ф0УЛ0Р фрагмент кода, приведенный в листинге 31-4, схема отсту-

(Martia Fowter) пов в котором заставляет человека думать, что все три выражения выполняются при каждом проходе цикла.

Листинг 31-4. Пример форматирования, рассказывающего разные истории человеку и компьютеру (Java)

меняем местами правые и левые элементы во всем массиве for ( i - 0; i < MAX ELEMENTS; i++ )

leftElement = left[ i ];

left[ i ] = right[ i ];

right[ 1 ] = leftElement;

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

Листинг 31-5. Другой пример форматирования, рассказывающего разные истории человеку и компьютеру (Java)

X = 3+4 * 2+7;

Человек, читающий этот код, будет склонен интерпретировать это выражение так, что переменной х присваивается значение (3+4) (2+7), т. е. 63. Компьютер проигнорирует пробелы и подчинится правилам приоритета, интерпретируя это выражение, как 3 + (4*2) + 7 или 18. Идея в том, что хорошая схема форматирования приведет в соответствие визуальную и логическую структуру программы, т. е. расскажет одну и ту же историю и человеку, и компьютеру.

Насколько важно хорошее форматирование?

Знание схем программирования и правил изложения программы может существенно повлиять на возможность осмысления программы. В книге «[ТЬе] Elements of [Programming] Style» Керниган и Плоджер (Kernighan and Plauger) также определяют то, что мы назвали правилами изложения. Наши эмпирические результаты подтверждают эти правила: необходимость написания программ в определенном стиле вызвана не только эстетическими соображениями. Создание программ в определенной манере имеет скорее психологическую подоплеку: программисты возлагают большие надежды на то, что другие разработчики будут следовать их правилам изложения. Если эти правила нарушаются, то вся польза, на которую надеется программист, сводится к нулю. Эти выводы подтверждаются результатами экспериментов с начи-



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