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

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

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

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

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

11.7. Имена, которых следует избегать

Ниже я описал некоторые типы имен, которых следует избегать.

Избегайте обманчивых имен или аббревиатур Убедитесь в том, что имя не является двусмысленным. Скажем, FALSE обычно является противоположностью TRUE, и использовать такое имя как сокращение фразы «Fig and Almond Season» было бы глупо.

Избегайте имен, имеющих похожие значения Если есть вероятность, что вы можете спутать имена двух переменных и это не приведет к ошибке компиляции, переименуйте обе переменных. Например, пары имен input и inputValue, recordNum и numRecords или fileNumber и filelndex так похожи с семантической точки зрения, что если вы будете использовать их в одном фрагменте кода, то сможете легко их спутать, внеся в код неуловимые ошибки.

Избегайте переменных, имеющих разную суть, но по-

хожие имена Если у вас есть две таких переменных, по- подобное рттт между пытайтесь переименовать одну из них или изменить аб- схоными тшт переменных бревиатуры. Избегайте имен вроде clientRecs и clientReps. Они называется «психологической различаются только одной буквой, и это трудно заметить, дистанцией» (см, пойраздел Выбирайте имена, различающиеся хотя бы двумя буквами J ттщт-

или первой/последней буквой. Имена clientRecords и сИ-entReports лучше, чем первоначальные имена.

Избегайте имен, имеющих похожее звучание, таких как wrap и rap Когда вы пытаетесь обсудить код с другими людьми, в разговор иногда вмешиваются омонимы. Так, одним из самых забавных аспектов экстремального программирования (Веек, 2000) является слишком хитрое использование терминов «Goal Donor» и «Gold Owner»\ которые звучат практически одинаково. В итоге разговор может принять подобный оборот:

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



- Я только что разговаривал с Goal Donor.

- Что ты сказал? «Gold Owner» или «Goal Donor»?

- Я сказал «Goal Donor».

- Что?

- GOAL - - - DONOR!

- Ясно, Goal Donor. He нужно кричать, черт возьми (Goir Darn it).

- Какое еще «золотое кольцо» (Gold Donut)?

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

Избегайте имен, включающих цифры Если наличие цифр в именах действительно имеет смысл, используйте вместо отдельных переменных массив. Если этот вариант неуместен, цифры в именах еще более неуместны. Например, избегайте имен filel и file2 или totall и total2. Почти всегда можно найти более разумный способ проведения различия между двумя переменными, чем дополнение их имен цифрами. В то же время я не могу сказать, что цифры нельзя использовать вообще. Некоторые сущности реального мира (такие как шоссе 66) изначально включают цифры. И все же перед созданием подобного имени подумайте, есть ли лучшие варианты.

Избегайте орфографических ошибок Вспомнить правильные имена переменных и так довольно трудно. Требовать запоминания «правильных» орфографических ошибок - это уж слишком. Например, если вы решите сэкономить три буквы и замените слово highlight на hilite, программисту, читающему код, будет неописуемо трудно вспомнить, на что же вы его заменили. На highlite? hilite? hilight? hilit? jai-a-lai-t? Кто его знает.

Избегайте слов, при написании которых люди часто допускают ошибки Absense, acummulate, acsend, calender, concieve, defferred, definate, independance, occassionally, prefered, reciept, superseed и многие другие орфографические ошибки весьма распространены в англоязычном мире. Список подобных слов можно найти в большинстве справочников по английскому языку. Не используйте такие слова в именах переменных.

Проводите различие между именами не только по регистру букв Если вы программируете на С++ или другом языке, в котором регистр букв играет роль, вы можете поддастся соблазну сократить понятря fired, final review duty и fill revenue disbursal соответственно до fid, FRD и Frd. Избегайте этого подхода. Хотя эти имена уникальны, их связь с конкретными значениями произвольна и непонятна. Имя Frd может с тем же успехом обозначать final review duty, а FRD -fill revenue disbursal, и никакое логическое правило не поможет вам или кому-то другому запомнить, что есть что.

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

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



лайте стандартом тот или иной вариант английского языка, чтобы вам не пришлось вспоминать, как называется конкретная переменная: «со1ог» или «colour», «check» или «cheque» и т. д.

Избегайте имен стандартных типов, переменных и методов Все языки программирования имеют зарезервированные и предопределенные имена. Просматривайте время от времени списки таких имен, чтобы не вторгаться во владения используемого языка. Так, следующий фрагмент вполне допустим при программировании на PL/I, но написать ТАКОЕ может только идиот со справкой:

if if = then then

then = else; else else = if;

He используйте имена, которые совершенно не связаны с тем, что представляют переменные Использование имен вроде margaret и pookie практически гарантирует, что никто другой их не поймет. Не называйте переменные в честь девушки, жены, любимого сорта пива и т. д., если только девушка, жена или сорт пива не являются представляемыми в программе «сущностями». Но даже тогда вы должны понимать, что все в мире изменяется, поэтому имена девушка, жена и любимыйСортПива гораздо лучше!

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

eyeChartl eyeChartl eyeChartl

TTLCONFUSION TTLCONFUSION TTLCONFUSION hard2Reacl hardZRead hard2Read

GRANDTOTAL GRANDTOTAL 6RANDT0TAL

ttl5 ttlS ttlS

В число пар символов, которые трудно различить, входят пары (1 и 1), (1 и I), С и ,), (О и О), (2 и 2), (; и :), (S и 5) и (G и 6).

Действительно ли важны подобные детали? Да! Джеральд

Вайнберг пишет, что в 1970-х из-за того, что в команде кшк)еся использования дан

FORMAT языка Fortran вместо точки была использована за- „ух, приведены в контрольном

пятая, ученые неверно рассчитали траекторию космичес- списке а главе 10, кого корабля и потеряли космический зонд стоимостью 1,6 млрд долларов (Weinberg, 1983).

Контрольный список: именование переменных

http: cc2e.cofn/1191

Общие принципы именования переменных

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

□ Характеризует ли имя проблему реального мира, а не ее решение на языке программирования?



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