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

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

Стандартизованные префиксы делают имена более компактными. Так, переменной, определяющей число абзацев, можно присвоить имя сра, 2. не totalParagrapbs. Индекс массива абзацев можно назвать ipa, 2. не indexParagrapbs или paragrapbslndex.

Наконец, стандартизованные префиксы облегчают проверку правильности использования абстрактных типов данных, когда компилятор оказывается беспомощным. Так, выражение paReformat = docReformat скорее всего ошибочно, потому что аббревиатуры ра и doc соответствуют разным UDT.

Главная ловушка при использовании стандартизованных префиксов - отказ от дополнения префикса выразительным именем переменной. Так, если имя ipa однозначно определяет индекс массива абзацев, есть соблазн не присваивать переменной более выразительное имя, такое как ipoActiveDocument. Помните про удобочитаемость кода и присваивайте переменным описательные имена.

11.6. Грамотное сокращение имен переменных

Стремление к сокращению имен переменных в некотором смысле стало пережитком. В более старых языках, таких как ассемблер, обычный Basic и Fortran, имена переменных были ограничены 2-8 символами. Кроме того, раньше программирование было более тесно связано с математикой, что побуждало использовать в уравнениях и других выражениях переменные с «математическими» именами /,7, и т. п. С++, Java, Visual Basic и другие современные языки позволяют создавать имена почти любой длины, поэтому сокращение выразительных имен уже не имеет под собой практически никаких оснований.

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

Общие советы по сокращению имен

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

используйте стандартные аббревиатуры (общепринятые, которые можно найти в словаре);

удаляйте все гласные, не являющиеся первыми буквами имен {computer - cmptr, screen - scm, apple - appl, integer - intgr);

удаляйте артикли и союзы, такие как and, or, tbe и т. д.;

сохраняйте одну или несколько первых букв каждого слова;

«обрезайте» слова согласованно: после первой, второй или третьей буквы (выбирайте вариант, уместный в конкретном случае);

сохраняйте первую и последнюю буквы каждого слова;

сохраняйте до трех выразительных слов;

удаляйте бесполезные суффиксы: ing, ed и т. д.



сохраняйте наиболее выразительный звук каждого слога;

проверяйте, чтобы смысл имени переменной в ходе сокращения не искажался;

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

Фонетические аббревиатуры

Некоторые люди сокращают слова, опираясь на их звучание, а не написание. В результате skating превращается в skSing, highlight - в hilite, before - в Ь4, execute - в xqt и т. д. Этот способ не отличается понятностью, поэтому я рекомендую забыть про него. Попробуйте, например, догадаться, что означают имена: ILV2SK8 XMEQWK S2DTM80 NXTC TRMN8R

Комментарии по поводу сокращения имен

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

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

Согфащайте имена согласованно Всегда используйте один и тот же вариант сокращения - например, только Num или только No, но не оба варианта. Аналогично не сокращайте слово только в некоторых именах. Если в одних именах вы использовали слово Number, не сокращайте его в других именах до Num и наоборот.

Сокращайте имена так, чтобы их можно было произнести Используйте имена xPos и needsComp, а не xPstn и ndsCmptg. Возьмите на заметку телефонный тест: если вы не можете прочитать код другому человеку по телефону, присвойте переменным более членораздельные имена (Kernighan and Plauger, 1978).

Избегайте комбинаций, допускающих неверное прочтение или произношение имени Если вам нужно как-то обозначить конец В, назовите переменную ENDB, 2i не BEND. Если вы грамотно разделяете части имен, этот совет вам не понадобится, так как сочетания B-END, BEnd или bend нельзя произнести неправильно.

Обращайтесь к словарю для разрешения конфликтов имен При сокращении некоторых имен в итоге получается одна и та же аббревиатура. Так, если длина имени ограничена тремя символами и вам нужно использовать в одной части программы элементы fired и full revenue disbursal, вы можете по неосторожности сократить оба варианта до frd.

Предотвратить конфликт имен позволяют синонимы, и тут на помощь приходит словарь. В нашем примере fired можно было бы заменить на синоним dismissed, а full revenue disbursal - на complete revenue disbursal. В итоге получаются аббревиатуры dsm и crd, что устраняет конфликт имен.



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

Пример хорошей таблицы преобразования (Fortran)

с Translation Table С

С Variable Meaning

С XPOS x-Coordinate Position (in meters)

С YPOS Y-Coordinate Position (in meters)

С NDSCMP Needs Computing (=0 if no computation is needed;

С =1 if computation is needed)

С PTGTTL Point Grand Total

С PTVLMX Point Value Maximum

С PSCRMX Possible Score Maximum

Может показаться, что этот способ устарел, но не далее чем в середине 2003 г. я работал с клиентом, который использовал программу на языке RPG, включавшую несколько сотен тысяч строк кода. Длина имен переменных в ней была ограничена 6 символами. Подобные проблемы все еще всплывают время от времени.

Указывайте все сокращения в проектном документе «Стандартные аббревиатуры Применение аббревиатур сопряжено с двумя распространенными факторами риска:

аббревиатура может оказаться непонятной программисту, читающему код;

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

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

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



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