Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 11 Сила имен переменных 275 сохраняйте наиболее выразительный звук каждого слога; проверяйте, чтобы смысл имени переменной в ходе сокращения не искажался; используйте эти способы, пока не сократите имя каждой переменной до 8–20 символов или до верхнего предела, ограничивающего длину имен в конкрет# ном языке. Фонетические аббревиатуры Некоторые люди сокращают слова, опираясь на их звучание, а не написание. В результате skating превращается в sk8ing, highlight — в hilite, before — в b4, execute — в xqt и т. д. Этот способ не отличается понятностью, поэтому я рекомендую забыть про него. Попробуйте, например, догадаться, что означают имена: ILV2SK8 XMEQWK S2DTM8O NXTC TRMN8R Комментарии по поводу сокращения имен Сокращая имена, вы можете попасть в одну из нескольких ловушек. Ниже описа# ны некоторые правила, позволяющие их избежать. Не сокращайте слова только на один символ Напечатать лишний символ не так уж трудно, и экономия одного символа едва ли может оправдать ухудше# ние удобочитаемости кода. При этом имена становятся похожими на названия ме# сяцев в календаре. Нужно очень уж сильно торопиться, чтобы написать «Июн» вме# сто «Июнь». Обычно после сокращения слов на один символ потом трудно вспом# нить, действительно ли вы удалили этот символ. Или удаляйте более одного сим# вола, или пишите все слово. Сокращайте имена согласованно Всегда используйте один и тот же вариант сокращения — например, только Num или только No, но не оба варианта. Аналогич# но не сокращайте слово только в некоторых именах. Если в одних именах вы ис# пользовали слово Number, не сокращайте его в других именах до Num и наоборот. Сокращайте имена так, чтобы их можно было произнести Используйте имена xPos и needsComp, а не xPstn и ndsCmptg. Возьмите на заметку телефонный тест: если вы не можете прочитать код другому человеку по телефону, присвойте переменным более членораздельные имена (Kernighan and Plauger, 1978). Избегайте комбинаций, допускающих неверное прочтение или произно' шение имени Если вам нужно как#то обозначить конец B, назовите переменную ENDB, а не BEND. Если вы грамотно разделяете части имен, этот совет вам не пона# добится, так как сочетания B%END, BEnd или b_end нельзя произнести неправильно. Обращайтесь к словарю для разрешения конфликтов имен При сокраще# нии некоторых имен в итоге получается одна и та же аббревиатура. Так, если длина имени ограничена тремя символами и вам нужно использовать в одной части программы элементы fired и full revenue disbursal, вы можете по неосторожности сократить оба варианта до frd. Предотвратить конфликт имен позволяют синонимы, и тут на помощь приходит словарь. В нашем примере fired можно было бы заменить на синоним dismissed, а full revenue disbursal — на complete revenue disbursal. В итоге получаются аббреви# атуры dsm и crd, что устраняет конфликт имен. 276 ЧАСТЬ III Переменные Документируйте очень короткие имена прямо в коде при помощи таб' лиц Если язык позволяет использовать только очень короткие имена, включай# те в код таблицу, характеризующую суть переменных. Включайте ее как коммен# тарий перед соответствующим блоком кода, например: Пример хорошей таблицы преобразования (Fortran) C ******************************************************************* C Translation Table C C Variable Meaning C ———— ——— C XPOS xCoordinate Position (in meters) C YPOS YCoordinate Position (in meters) C NDSCMP Needs Computing (=0 if no computation is needed; C =1 if computation is needed) C PTGTTL Point Grand Total C PTVLMX Point Value Maximum C PSCRMX Possible Score Maximum C ***************************************************************** Может показаться, что этот способ устарел, но не далее чем в середине 2003 г. я работал с клиентом, который использовал программу на языке RPG, включавшую несколько сотен тысяч строк кода. Длина имен переменных в ней была ограни# чена 6 символами. Подобные проблемы все еще всплывают время от времени. Указывайте все сокращения в проектном документе «Стандартные аб' бревиатуры» Применение аббревиатур сопряжено с двумя распространенны# ми факторами риска: аббревиатура может оказаться непонятной программисту, читающему код; программисты могут сократить одно и то же имя по#разному, что вызывает ненужное замешательство. Для предотвращения этих потенциальных проблем вы можете создать документ «Стандартные аббревиатуры», описывающий все аббревиатуры конкретного про# екта. Сам документ может быть файлом текстового редактора или электронной таблицей. При работе над очень крупным проектом им может быть база данных. Этот документ следует зарегистрировать в системе управления версиями и изме# нять его каждый раз, когда кто#то создает новую аббревиатуру. Элементы доку# мента должны быть сортированы по полным словам, а не по аббревиатурам. Может показаться, что эта методика связана с большим объемом дополнительной работы, но на самом деле она требует небольших усилий на начальном этапе, предоставляя взамен механизм, помогающий эффективно использовать аббреви# атуры. Она устраняет первый из двух факторов риска, заставляя документировать все используемые аббревиатуры. Если программист не может создать новую аб# бревиатуру, не проверив документ «Стандартные аббревиатуры», не изменив его и снова не зарегистрировав в системе управления версиями, — это хорошо. Это значит, что программисты будут создавать аббревиатуры, только когда будут чув# ствовать, что выгода от их создания стоит того, чтобы преодолеть все барьеры, связанные с их документированием. ГЛАВА 11 Сила имен переменных 277 Вероятность создания избыточных аббревиатур также снижается. Программист, желающий сократить какое#то слово, должен будет проверить документ и ввести новую аббревиатуру. Если это слово уже было сокращено, программист заметит это и будет использовать существующую аббревиатуру. Этот совет иллюстрирует различие между удобством написания кода и удобством его чтения. Очевидно, что рассмотренный подход делает на# писание кода менее удобным, однако на протяжении срока службы сис# темы программисты проводят гораздо больше времени именно за чтением кода, которое благодаря этому подходу облегчается. Когда вся пыль осядет, вполне может оказаться, что этот подход облегчил и написание кода. Помните, что имена создаются в первую очередь для программистов, читающих код Прочитайте собственный код, который вы не видели минимум шесть месяцев, и обратите внимание на те имена, суть которых вы не можете понять с первого взгляда. Измените подходы, подталкивающие к выбору таких имен. 11.7. Имена, которых следует избегать Ниже я описал некоторые типы имен, которых следует избегать. Избегайте обманчивых имен или аббревиатур Убедитесь в том, что имя не является двусмысленным. Скажем, FALSE обычно является противоположностью TRUE, и использовать такое имя как сокращение фразы «Fig and Almond Season» было бы глупо. Избегайте имен, имеющих похожие значения Если есть вероятность, что вы можете спутать имена двух переменных и это не приведет к ошибке компиляции, переименуйте обе переменных. Например, пары имен input и inputValue, recordNum и numRecords или fileNumber и fileIndex так похожи с семантической точки зре# ния, что если вы будете использовать их в одном фрагменте кода, то сможете легко их спутать, внеся в код неуловимые ошибки. Избегайте переменных, имеющих разную суть, но по' хожие имена Если у вас есть две таких переменных, по# пытайтесь переименовать одну из них или изменить аб# бревиатуры. Избегайте имен вроде clientRecs и clientReps. Они различаются только одной буквой, и это трудно заметить. Выбирайте имена, различающиеся хотя бы двумя буквами или первой/последней буквой. Имена clientRecords и cli% entReports лучше, чем первоначальные имена. Избегайте имен, имеющих похожее звучание, таких как wrap и rap Когда вы пытаетесь обсудить код с другими людьми, в разговор иногда вмешиваются омонимы. Так, одним из самых забавных аспектов экстремального программиро# вания (Beck, 2000) является слишком хитрое использование терминов «Goal Donor» и «Gold Owner» 1 , которые звучат практически одинаково. В итоге разговор может принять подобный оборот: Перекрестная ссылка Техниче- ски подобное различие между сходными именами переменных называется «психологической дистанцией» (см. подраздел «Психологическая дистанция» раздела 23.4). 1 Что буквально переводится как «донор цели» и «владелец золота». В экстремальном програм# мировании так называют роли людей, соответственно ставящих перед разработчиками задачу и финансирующих проект. — Прим. перев. 278 ЧАСТЬ III Переменные — Я только что разговаривал с Goal Donor. — Что ты сказал? «Gold Owner» или «Goal Donor»? — Я сказал «Goal Donor». — Что? — GOAL # # # DONOR! — Ясно, Goal Donor. Не нужно кричать, черт возьми (Goll’ Darn it). — Какое еще «золотое кольцо» (Gold Donut)? Как и в случае непроизносимых аббревиатур, используйте для исключения подоб# ных ситуаций телефонный тест. Избегайте имен, включающих цифры Если наличие цифр в именах действи# тельно имеет смысл, используйте вместо отдельных переменных массив. Если этот вариант неуместен, цифры в именах еще более неуместны. Например, избегайте имен file1 и file2 или total1 и total2. Почти всегда можно найти более разумный способ проведения различия между двумя переменными, чем дополнение их имен цифрами. В то же время я не могу сказать, что цифры нельзя использовать вооб# ще. Некоторые сущности реального мира (такие как шоссе 66) изначально вклю# чают цифры. И все же перед созданием подобного имени подумайте, есть ли луч# шие варианты. Избегайте орфографических ошибок Вспомнить правильные имена перемен# ных и так довольно трудно. Требовать запоминания «правильных» орфографиче# ских ошибок — это уж слишком. Например, если вы решите сэкономить три бук# вы и замените слово highlight на hilite, программисту, читающему код, будет нео# писуемо трудно вспомнить, на что же вы его заменили. На highlite? hilite? hilight? hilit? jai%a%lai%t? Кто его знает. Избегайте слов, при написании которых люди часто допускают ошиб' ки Absense, acummulate, acsend, calender, concieve, defferred, definate, independance, occassionally, prefered, reciept, superseed и многие другие орфографические ошиб# ки весьма распространены в англоязычном мире. Список подобных слов можно найти в большинстве справочников по английскому языку. Не используйте такие слова в именах переменных. Проводите различие между именами не только по регистру букв Если вы программируете на C++ или другом языке, в котором регистр букв играет роль, вы можете поддастся соблазну сократить понятия fired, final review duty и full revenue disbursal соответственно до frd, FRD и Frd. Избегайте этого подхода. Хотя эти имена уникальны, их связь с конкретными значениями произвольна и непонятна. Имя Frd может с тем же успехом обозначать final review duty, а FRD — full revenue disbursal, и никакое логическое правило не поможет вам или кому#то другому запомнить, что есть что. Избегайте смешения естественных языков Если в проекте участвуют програм# мисты разных национальностей, обяжите их именовать все элементы программы, используя один естественный язык. Понять код другого программиста непросто; а код, написанный на юго#восточном диалекте марсианского языка, — невозможно. Еще более тонкая проблема связана с наличием разных диалектов английского языка. Если в проекте участвуют представители разных англоязычных стран, сде# ГЛАВА 11 Сила имен переменных 279 лайте стандартом тот или иной вариант английского языка, чтобы вам не при# шлось вспоминать, как называется конкретная переменная: «color» или «colour», «check» или «cheque» и т. д. Избегайте имен стандартных типов, переменных и методов Все языки программирования имеют зарезервированные и предопределенные имена. Про# сматривайте время от времени списки таких имен, чтобы не вторгаться во владе# ния используемого языка. Так, следующий фрагмент вполне допустим при про# граммировании на PL/I, но написать ТАКОЕ может только идиот со справкой: if if = then then then = else; else else = if; Не используйте имена, которые совершенно не связаны с тем, что пред' ставляют переменные Использование имен вроде margaret и pookie практи# чески гарантирует, что никто другой их не поймет. Не называйте переменные в честь девушки, жены, любимого сорта пива и т. д., если только девушка, жена или сорт пива не являются представляемыми в программе «сущностями». Но даже тогда вы должны понимать, что все в мире изменяется, поэтому имена девушка, жена и любимыйСортПива гораздо лучше! Избегайте имен, содержащих символы, которые можно спутать с дру' гими символами Помните, что некоторые символы выглядят очень похоже. Если два имени различаются только одним таким символом, вы можете столкнуться с проблемами. Попробуйте, например, определить, какое из имен является лишним в каждой тройке: eyeChartl eyeChartI eyeChartl TTLCONFUSION TTLCONFUSION TTLC 0 NFUSION hard2Read hardZRead hard2Read GRANDTOTAL GRANDTOTAL 6RANDTOTAL ttl5 ttlS ttlS В число пар символов, которые трудно различить, входят пары (1 и l), (1 и I), (. и ,), (0 и O), (2 и Z), (; и :), (S и 5) и (G и 6). Действительно ли важны подобные детали? Да! Джеральд Вайнберг пишет, что в 1970#х из#за того, что в команде FORMAT языка Fortran вместо точки была использована за# пятая, ученые неверно рассчитали траекторию космичес# кого корабля и потеряли космический зонд стоимостью 1,6 млрд долларов (Weinberg, 1983). Контрольный список: именование переменных Общие принципы именования переменных Описывает ли имя представляемую переменной сущность полно и точно? Характеризует ли имя проблему реального мира, а не ее решение на языке программирования? Перекрестная ссылка Вопросы, касающиеся использования дан- ных, приведены в контрольном списке в главе 10. http://cc2e.com/1191 280 ЧАСТЬ III Переменные Имеет ли имя длину, достаточную для того, чтобы над ним не нужно было ломать голову? Спецификаторы вычисляемых значений находятся в конце имен? Используются ли в именах спецификаторы Count или Index вместо Num? Именование конкретных видов данных Выразительные ли имена присвоены индексам циклов (более ясные, чем i, j и k, если цикл содержит более одной-двух строк или является вложенным)? Всем ли «временным» переменным присвоены выразительные имена? Можно ли по именам булевых переменных понять, какой смысл имеют зна- чения «истина» и «ложь»? Включают ли имена элементов перечислений префикс или суффикс, опре- деляющий принадлежность элемента к перечислению — например, префикс Color_ в случае элементов Color_Red, Color_Green, Color_Blue и т. д.? Именованные константы названы в соответствии с представляемыми абст- рактными сущностями, а не конкретными числами? Конвенции именования Проводит ли конвенция различие между локальными данными, данными класса и глобальными данными? Проводит ли конвенция различие между именами типов, именованных кон- стант, перечислений и переменных? Идентифицировали ли вы исключительно входные параметры методов, если язык не навязывает их идентификацию? Постарались ли вы сделать конвенцию как можно более совместимой со стандартными конвенциями конкретного языка? Способствует ли форматирование имен удобству их чтения? Короткие имена Стараетесь ли вы не сокращать имена без необходимости? Избегаете ли вы сокращения имен только на одну букву? Все ли слова вы сокращаете согласованно? Легко ли произнести выбранные имена? Избегаете ли вы имен, допускающих неверное прочтение или произношение? Документируете ли вы короткие имена при помощи таблиц преобразования? Распространенные проблемы именования. Избежали ли вы… …имен, которые вводят в заблуждение? …имен с похожими значениями? …имен, различающихся только одним или двумя символами? …имен, имеющих похожее звучание? …имен, включающих цифры? …имен, намеренно написанных с ошибками с целью сокращения? …имен, при написании которых люди часто допускают ошибки? …имен, конфликтующих с именами методов из стандартных библиотек или предопределенными именами переменных? …совершенно произвольных имен? …символов, которые можно спутать с другими символами? ГЛАВА 11 Сила имен переменных 281 Ключевые моменты Выбор хороших имен переменных — одно из главных условий понятности программы. С отдельными типами переменных — например, с индексами цик# лов и переменными статуса — связаны свои принципы именования. Имена должны быть максимально конкретны. Имена, которые из#за невыра# зительности или обобщенности можно использовать более чем с одной целью, обычно являются плохими. Конвенции именования позволяют провести различие между локальными дан# ными, данными класса и глобальными данными, а также между именами ти# пов, именованных констант, перечислений и переменных. Над каким бы проектом вы ни работали, вам следует принять конвенцию име# нования переменных. При выборе типа конвенции следует учитывать размер программы и число работающих над ней программистов. Современные языки программирования позволяют отказаться от сокращения имен. Если вы все#таки сокращаете имена, регистрируйте аббревиатуры в сло# варе проекта или используйте стандартизированные префиксы. За чтением кода программисты проводят гораздо больше времени, чем за его написанием. Выбирайте имена так, чтобы они облегчали чтение кода, пусть даже за счет удобства его написания. 282 ЧАСТЬ III Переменные Г Л А В А 1 2 Основные типы данных Содержание 12.1. Числа в общем 12.2. Целые числа 12.3. Числа с плавающей запятой 12.4. Символы и строки 12.5. Логические переменные 12.6. Перечислимые типы 12.7. Именованные константы 12.8. Массивы 12.9. Создание собственных типов данных (псевдонимы) Связанные темы Присвоение имен данным: глава 11 Нестандартные типы данных: глава 13 Общие вопросы использования переменных: глава 10 Описание форматов данных: подраздел «Размещение объявлений данных» раздела 31.5 Документирование переменных: подраздел «Комментирование объявлений дан# ных» раздела 32.5 Создание классов: глава 6 Основные типы данных являются базовыми блоками для построения остальных типов данных. Эта глава содержит советы по применению чисел вообще, целых чисел, чисел с плавающей запятой, символов и строк, логических переменных, перечислимых типов, именованных констант и массивов. В заключительном раз# деле этой главы рассказано о создании собственных типов данных. Эта глава содержит рекомендации по предупреждению главных ошибок в приме# нении основных типов данных. Если вы уже ознакомились с основами, перехо# дите к концу главы, к обзору перечня допускаемых ошибок, а также к обсужде# нию нестандартных типов данных в главе 13. http://cc2e.com/1278 |