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

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

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

-Эллиот Соловей и Кейт Эрлих (Elliot Soloway and Kate Ehrlich)

В вопросах форматирования, возможно, сильнее, чем в дру- щщтт сешк» Хорошее

гих аспектах программирования, проявляется разница между щшчщшт - один из

взаимодействием с компьютером и взаимодействием с чело- ключей к щШшттт (см,

веком. Меньшая задача программирования состоит в напи- PW 34.3).

сании программы в понятном для компьютера виде, большая

- в том, чтобы написать ее так, чтобы другие люди могли ее прочесть.

В классической статье «Perception in Chess» Чейз и Саймон (Chase and Simon) сообщили об исследовании, в котором сравнивались способности экспертов и новичков запоминать позиции фигур в шахматах (1973). Когда фигуры были расставлены так, как это могло сложиться во время игры, память экспертов во много раз превосходила способности начинающих. Когда же фигуры были расставлены случайно, то результаты экспертов и новичков отличались не намного. Традиционно этот результат объясняется тем, что память эксперта несущественно отличается от памяти начинающих, но эксперты используют систему знаний, помогающую им запоминать определенные виды информации. Если новые данные соответствуют этой системе знаний (в данном случае осмысленному размещению шахматных фигур), эксперты легко могут их запомнить. Если же новая информация в эту систему не укладывается (шахматные фигуры расположены в случайном порядке) эксперт может запомнить ее ничуть не лучше новичка.

Несколько лет спустя Бен Шнейдерман (Ben Shneiderman) повторил результаты Чейза и Саймона в сфере компьютерного программирования и сообщил о них в статье «Exploratory Experiments in Programmer Behavior» (1976). Шнейдерман выяснил, что если программные операторы расположены в осмысленном порядке, то эксперты могли запомнить их лучше, чем новички. Когда же операторы перемешивались, преимущество экспертов снижалось. Результаты Шнейдермана были подтверждены и в других исследованиях (McKeithen et al., 1981; Soloway and Ehrlich, 1984). Основная концепция подтверждалась в играх го и бридже, а также в электронике, музыке и физике (McKeithen et al., 1981).

После публикации первого издания этой книги Хенк - один из программистов, рецензировавших рукопись, - сказал: «Я удивился, что ты недостаточно активно ратовал за использование такого стиля скобок:

for ( ...)

Странно, что ты вообще упомянул такой стиль скобок, как этот:

for (...) {

я думал, что, поскольку и я, и Тони приводили доводы в пользу первого стиля, ты предпочтешь его».



Я ответил: «Ты, наверное, имел в виду, что ты ратовал за применение первого стиля, а Тони - второго, не так ли? Тони приводил доводы в пользу второго стиля, а не первого».

Хенк ответил: «Забавно. В последнем проекте, над которым Тони и я работали вместе, я предпочитал использовать стиль №2, а Тони - №1. Весь проект мы спорили о том, какой стиль лучше. Полагаю, мы уговорили друг друга предпочесть противоположный стиль!»

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

Форматирование как религия

Важное влияние, которое привычный способ структурирования среды оказывает на процесс понимания и запоминания, заставило исследователей выдвинуть такую гипотезу: если форматирование отличается от схемы, используемой экспертами, оно может повредить их способности читать программу (Shell, 1981; Soloway and Ehrlich, 1984). Такая возможность вкупе с не только логическим, но и эстетическим значением форматирования привела к тому, что дебаты вокруг форматирования программ часто больше похожи на религиозные войны, а не на философские диспуты.


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

Шродветш ссшка Еспи вы смешиваете вопросы разработки ПО и рвтгт, прочтите раздел 34.9. прежде чем продолжить чтение остальной части шй гты*



Цели хорошего форматирования

Многие решения о том, как должно выглядеть хорошее фор-

матирование, представляют собой субъективные эстетичес- щ. праграммкотской шпи-кие оценки; часто можно достичь одной и той же цели по- фшр»: опытные програшнс-разному Вы можете сделать споры о субъективных вопро- шщттспШтщтштнт сах менее субъективными, если явно укажете критерии ва- должны выглядеть

ших предпочтений. Говоря объективно, хорошая схема фор- lpf!!i матирования должна делать следующие вещи. безобидными сяособами!

Точно представлять логическую структуру кода Сно- прошводитеяьйость рти-ва повторим Основную теорему форматирования: главная ухушается.

цель хорошего форматирования - показать логическую Эллтт ОотШ

структуру кода. Для демонстрации логической структуры (Еш\ту

программисты обычно применяют отступы и другие не- j С ЕЬгИЩ

отображаемые символы.

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

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

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

В дополнение к этим критериям иногда во внимание принимается и задача минимизации количества строк кода, необходимых для реализации простого выражения или блока.

Как воспользоваться принципами хорошего форматирования на практике

Критерии хорошей схемы форматирования могут служить основой для обсуждения возможных вариантов форматов, помогая отличить субъективные причины в предпочтении одного стиля форматирования перед другим

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



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