Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 11 Сила имен переменных 261 Именование булевых переменных Ниже я привел ряд рекомендаций по именованию булевых переменных. Помните типичные имена булевых переменных Вот некоторые наиболее полезные имена булевых переменных. 쐽 done Используйте переменную done как признак завершения цикла или дру- гой операции. Присвойте ей false до выполнения действия и установите ее в true после его завершения. 쐽 error Используйте переменную error как признак ошибки. Присвойте ей зна- чение false, если все в порядке, и true в противном случае. 쐽 found Используйте переменную found для определения того, обнаружено ли некоторое значение. Установите ее в false, если значение не обнаружено, и в true, как только значение найдено. Используйте переменную found при поис- ке значения в массиве, идентификатора сотрудника в файле, определенного чека в списке чеков и т. д. 쐽 success или ok Используйте переменную success или ok как признак успешно- го завершения операции. Присвойте ей false, если операция завершилась не- удачей, и true, если операция выполнена успешно. Если можете, замените имя success на более определенное, ясно определяющее смысл «успеха». Если под «успехом» понимается завершение обработки данных, можете назвать перемен- ную processingComplete. Если «успех» подразумевает обнаружение конкретно- го значения, можете использовать переменную found. Присваивайте булевым переменным имена, подразумевающие значение true или false Имена вроде done и success — хорошие имена булевых перемен- ных, потому что они предполагают использование только значений true или false: что-то может быть или выполнено, или не выполнено, операция может завершиться или успехом, или неудачей. С другой стороны, имена вроде status и sourceFile не годятся, так как при этом значения true или false не имеют ясного смысла. Какой вывод можно сделать, если переменной status задано true? Означает ли это, что что-то имеет статус? Все имеет статус. Означает ли это, что что-то имеет статус «все в порядке»? Означает ли значение false, что никакое действие не было выпол- нено неверно? Если переменная имеет имя status, ничего определенного на сей счет сказать нельзя. Поэтому имя status лучше заменить на имя вроде error или statusOK, а имя source- File — на sourceFileAvailable, sourceFileFound или подобное имя, соответствующее сути переменной. Некоторые программисты любят дополнять имена булевых переменных префик- сом is. В результате имя переменной превращается в вопрос: isdone? isError? isFound? isProcessingComplete? Ответ на этот вопрос сразу становится и значением перемен- ной. Достоинство этого подхода в том, что он исключает использование неопре- деленных имен: вопрос isStatus? не имеет никакого смысла. Однако в то же время он затрудняет чтение логических выражений: например, условие if ( isFound ) менее понятно, чем if ( found ). 262 ЧАСТЬ III Переменные Используйте утвердительные имена булевых переменных Имена, основан- ные на отрицании (такие как notFound, notdone и notSuccessful), при выполнении над переменной операции отрицания становятся куда менее понятны, например: if not notFound Подобные имена следует заменить на found, done и processingComplete, выполняя отрицание переменных в случае надобности. Так что для проверки нужного зна- чения вы использовали бы выражение found, а не not notFound. Именование перечислений Принадлежность переменных к тому или иному перечисле- нию можно пояснить, дополнив их имена префиксами, та- кими как Color_, Planet_ или Month_: Пример дополнения элементов перечислений префиксами (Visual Basic) Public Enum Color Color_Red Color_Green Color_Blue End Enum Public Enum Planet Planet_Earth Planet_Mars Planet_Venus End Enum Public Enum Month Month_January Month_February Month_December End Enum Кроме того, сами перечисления ( Color, Planet или Month) можно идентифициро- вать разными способами: например, используя в их именах только заглавные буквы или дополняя их имена префиксами ( e_Color, e_Planet или e_Month). Кое-кто мог бы сказать, что перечисление по сути является типом, определяемым пользовате- лем, поэтому имена перечислений надо форматировать так же, как имена клас- сов и других пользовательских типов. С другой стороны, члены перечислений являются константами, поэтому имена перечислений следует форматировать как имена констант. В этой книге я придерживаюсь конвенции, предусматривающей применение в именах перечислений букв обоих регистров. В некоторых языках перечисления рассматриваются скорее как классы, а именам членов перечисления всегда предшествует имя самого перечисления, например, Color.Color_Red или Planet.Planet_Earth. Если вы используете подобный язык, по- вторять префикс не имеет смысла, так что вы можете считать префиксом само имя перечисления и сократить имена до Color.Red и Planet.Earth. Перекрестная ссылка О пере- числениях см. раздел 12.6. ГЛАВА 11 Сила имен переменных 263 Именование констант Имя константы должно характеризовать абстрактную сущ- ность, представляемую константой, а не конкретное значе- ние. Имя FIVE — плохое имя константы (независимо от того, имеет ли она значение 5.0). CYCLES_NEEDED — хорошее имя. CYCLES_NEEDED может иметь значение 5.0, 6.0 и любое другое. Выражение FIVE = 6.0 было бы странным. Аналогично BAKERS_DOZEN — плохое имя константы, а DONUTS_MAX — вполне подходящее. 11.3. Сила конвенций именования Программисты предпочитают порой не использовать стандарты и конвенции по вполне разумной причине. Некоторые стандарты и конвенции, слишком жесткие и неэффективные, подавляют творчество и снижают качество программы. Это пе- чально, так как эффективные стандарты — один из мощнейших инструментов. В этом разделе мы обсудим, почему, когда и как создавать собственные стандарты именования переменных. Зачем нужны конвенции? Конвенции обеспечивают несколько преимуществ. 쐽 Они позволяют больше принимать как данное. Приняв одно общее решение вместо нескольких более узких, вы сможете сосредоточиться на более важных аспектах кода. 쐽 Они помогают использовать знания, полученные при работе над предыдущи- ми проектами. Сходство имен облегчает понимание незнакомых переменных. 쐽 Они ускоряют изучение кода нового проекта. Вместо изучения особенностей кода Аниты, Джулии и Кристин вы сможете работать с более согласованным кодом. 쐽 Они подавляют «размножение» имен. Не применяя конвенцию именования, вы легко можете присвоить одной сущности два разных имени. Скажем, вы мо- жете назвать общее число баллов и pointTotal, и totalPoints. Возможно, при на- писании программы вам все будет понятно, но другой программист, который попытается понять такой код позднее, может столкнуться с серьезными про- блемами. 쐽 Они компенсируют слабости языка. Вы можете использовать конвенции для имитации именованных констант и перечислений. Конвенции позволяют про- вести грань между локальными данными, данными класса и глобальными дан- ными, а также охарактеризовать типы, не поддерживаемые компилятором. 쐽 Они подчеркивают отношения между связанными элементами. Если вы исполь- зуете данные объектов, компилятор заботится об этом автоматически. Если язык не поддерживает объекты, вы можете свести этот недостаток к минимуму при помощи конвенции именования. Так, имена address, phone и name не говорят о том, что эти переменные связаны между собой. Но если вы решите допол- нять все переменные, хранящие данные о сотрудниках, префиксом Employee, эта связь будет ясно выражена в итоговых именах employeeAddress, employeePhone и employeeName. Конвенции программирования могут устранить недостатки используемого вами языка. Перекрестная ссылка Об имено- ванных константах см. раздел 12.7. 264 ЧАСТЬ III Переменные Суть сказанного в том, что наличие хоть какой-то конвенции обычно пред- почтительнее, чем ее отсутствие. Конвенция может быть произвольной. Сила конвенций именования объясняется не конкретными аспектами, а самим фактом их использования, обеспечивающим структурирование кода и умень- шающим количество поводов для беспокойства. Когда следует использовать конвенцию именования? Непреложных правил на этот счет нет, однако некоторые рекомендации дать можно. Итак, используйте конвенцию именования, если: 쐽 над проектом работают несколько программистов; 쐽 программу будут изменять и сопровождать другие программисты (что имеет место почти всегда); 쐽 обзор программы выполняют другие программисты из вашей компании; 쐽 программа так велика, что вы не можете полностью охватить ее умом, а вы- нуждены рассматривать по частям; 쐽 программа будет использоваться длительное время, из-за чего вам, возможно, придется вернуться к ней через несколько недель или месяцев; 쐽 прикладная область имеет необычную терминологию и вы хотите стандарти- зовать применение терминов или аббревиатур в коде. Использовать конвенции именования всегда выгодно, а мои советы помогут вам определить оптимальную детальность конвенции для конкретного проекта. Степень формальности конвенций Конвенциям именования могут соответствовать разные сте- пени формальности. Неформальная конвенция может быть совсем простой: «Используйте выразительные имена». Дру- гие неформальные конвенции рассматриваются в следую- щем разделе. В общем, оптимальная степень формальнос- ти конвенции определяется числом людей, работающих над программой, разме- ром программы и ожидаемым временем ее использования. При работе над кро- шечными проектами, подлежащими выбросу, следование строгой конвенции, наверное, окажется пустой тратой сил. В случае более крупных проектов, реали- зуемых с участием нескольких программистов, формальная конвенция — важней- шее средство улучшения удобочитаемости программы. 11.4. Неформальные конвенции именования В большинстве проектов используются относительно неформальные конвенции именования, подобные тем, что описываются в этом разделе. Конвенция, не зависящая от языка Ниже приведены некоторые советы по созданию конвенции, не зависящей от языка. Проведите различие между именами переменных и именами методов Конвенция, используемая в этой книге, подразумевает, что имена переменных и Перекрестная ссылка О разли- чиях формальности при рабо- те над небольшими и крупны- ми проектами см. главу 27. ГЛАВА 11 Сила имен переменных 265 объектов начинаются со строчной буквы, а имена методов — с прописной: variable- Name, но RoutineName(). Проведите различие между классами и объектами Соответствие между име- нами классов и объектов (или между именами типов и переменных этих типов) может быть довольно тонким. Некоторые стандартные способы проведения раз- личия между ними иллюстрирует следующий фрагмент: Вариант 1: имена типов отличаются от имен переменных регистром первой буквы Widget widget; LongerWidget longerWidget; Вариант 2: имена типов отличаются от имен переменных регистром всех букв WIDGET widget; LONGERWIDGET longerWidget Вариант 3: имена типов дополняются префиксом «t_» t_Widget Widget; t_LongerWidget LongerWidget; Вариант 4: имена переменных дополняются префиксом «a» Widget aWidget; LongerWidget aLongerWidget; Вариант 5: имена переменных более конкретны, чем имена типов Widget employeeWidget; LongerWidget fullEmployeeWidget; Каждый из этих вариантов имеет свои плюсы и минусы. Вариант 1 часто использу- ется при программировании на C++, Java и других языках, чувствительных к регист- ру букв, но некоторые программисты считают, что различать имена только по реги- стру первой буквы неудобно. Действительно, имена, отличающиеся только регист- ром первой буквы, имеют слишком малое психологическое и визуальное различие. Вариант 1 не удастся согласованно использовать при программировании на не- скольких языках, если хотя бы в одном из них регистр букв не имеет значения. Так, при компиляции команды Dim widget as Widget компилятор Microsoft Visual Basic сообщит о синтаксической ошибке, потому что widget и Widget покажутся ему одним и тем же элементом. Вариант 2 проводит более очевидное различие между именами типов и перемен- ных. Однако по историческим причинам в C++ и Java верхний регистр служит для определения констант, к тому же при разработке программы с использованием нескольких языков этот подход приводит к тем же проблемам, что и вариант 1. Вариант 3 поддерживается всеми языками, но некоторым программистам префиксы не нравятся по эстетическим причинам. Вариант 4 иногда используют как альтернативу варианту 3, но вместо изменения имени одного класса он требует модификации имени каждого экземпляра класса. 266 ЧАСТЬ III Переменные Вариант 5 заставляет тщательно обдумывать имя каждой переменной. Обычно результатом этого является более понятный код. Но иногда widget (приспособле- ние) на самом деле — всего лишь общее «приспособление», и в этих случаях вы должны будете придумывать менее ясные имена вроде genericWidget, которые, несомненно, читаются хуже. Короче, каждый из вариантов связан с компромиссами. В этой книге я использую вариант 5, потому что он наиболее понятен, если человеку, читающему код, неиз- вестны конвенции именования. Идентифицируйте глобальные переменные Одной из частых проблем про- граммирования является неверное использование глобальных переменных. Если вы присвоите всем глобальным переменным имена, начинающиеся, скажем, с пре- фикса g_, программист, увидевший переменную g_RunningTotal, сразу поймет, что это глобальная переменная, и будет обращаться с ней должным образом. Идентифицируйте переменные-члены Идентифицируйте данные-члены клас- са. Ясно покажите, что переменная-член не является ни локальной, ни глобаль- ной переменной. Идентифицировать переменные-члены класса можно, например, при помощи префикса m_. Идентифицируйте определения типов Конвенции именования типов играют две роли: они явно показывают, что имя является именем типа, и предотвращают конфликты имен типов и переменных. Для этого вполне годится префикс (суф- фикс). В C++ для именования типов обычно используют только заглавные буквы: например, COLOR и MENU. (Это справедливо для имен типов, определяемых с помощью директив typedef, и имен структур, но не классов.) Однако при этом можно спутать типы с именованными константами препроцессора. Для предотвращения путаницы можно дополнять имена типов префиксом t_, что дает нам такие име- на, как t_Color и t_Menu. Идентифицируйте именованные константы Именованные константы нуж- но идентифицировать, чтобы вы могли определить, присваиваете ли вы переменной значение другой переменной (которое может изменяться) или именованной кон- станты. В случае Visual Basic эти два варианта можно также спутать с присваива- нием переменной значения, возвращаемого функцией. Visual Basic не требует применения скобок при вызове функции, не принимающей параметров, тогда как в C++ скобки нужно указывать при вызове любой функции. Одним из подходов к именованию констант является применение префикса, на- пример c_. Это дает нам такие имена, как c_RecsMax или c_LinesPerPageMax. В случае C++ и Java конвенция подразумевает использование только заглавных букв без разделения слов или с разделением слов символами подчеркивания: RECSMAX или RECS_ MAX и LINESPERPAGEMAX или LINES_PER_PAGE_ MAX. Идентифицируйте элементы перечислений Элементы перечислений следует идентифицировать по той же причине, что и именованные константы: чтобы элемент перечисления можно было легко отличить от переменной, именованной константы или вызова функции. Стандартный подход предполагает применение в имени перечисления только заглавных букв или дополнение имени префиксом e_ или E_; что касается имен элементов, то они дополняются префиксом, осно- ванным на имени конкретного перечисления, скажем, Color_ или Planet_. ГЛАВА 11 Сила имен переменных 267 Идентифицируйте неизменяемые параметры, если язык не требует их явного определения Иногда программисты случайно изменяют входные пара- метры. C++, Visual Basic и некоторые другие языки заставляют явно указывать, хотите ли вы, чтобы изменения параметров внутри метода были доступны в остальном коде. Для этого служат спецификаторы *, & и const в C++ и ByRef/ByVal в Visual Basic. В случае других языков изменение входной переменной в методе отражается в остальном коде, хотите вы того или нет. Это особенно верно при передаче объектов. Например, в Java все объекты передаются в методы «значением», поэтому, пере- давая объект в метод, будьте готовы к тому, что состояние объекта может изме- ниться 1 (Arnold, Gosling, Holmes, 2000). Если, программируя на таком языке, вы следуете конвенции именования, согласно которой исключительно входные (неизменяемые) параметры нужно дополнять префиксом const (или final, или nonmodifiable, или каким-то аналогич- ным), то, увидев что-то с префиксом const слева от знака равенства, вы будете знать, что произошла ошибка. Если вы увидите вызов constMax.SetNewMax( ... ), вы также по префиксу const поймете, что это ошибка. Форматируйте имена так, чтобы их было легко читать Для повышения удобочитаемости кода слова в именах переменных часто разделяют заглавными буквами или символами-разделителями. Например, имя GYMNASTICSPOINTTOTAL читается хуже, чем gymnasticsPointTotal или gymnastics_point_total. C++, Java, Visual Basic и другие языки позволяют использовать оба этих подхода. Старайтесь не смешивать эти способы, так как это осложняет чтение кода. Если же вы будете согласованно использовать один из подходов, код станет более по- нятным. Программисты уже давно спорят по поводу того, делать ли заглавной первую букву имени ( TotalPoints или totalPoints), но если все участвующие в про- екте программисты будут поступать согласованно, подобные мелочи не будут играть особой роли. В данной книге имена переменных начинаются с буквы нижнего регистра по той причине, что этот подход принят в языке Java, а также для под- держания сходства стилей между разными языками. Конвенции, специфические для конкретных языков Соблюдайте конвенции именования, принятые в используемом вами языке. Книги по стилю программирования можно найти почти для любого языка. Советы, отно- сящиеся к языкам C, C++, Java и Visual Basic, даны в следующих подразделах. Конвенции C Конвенции именования, используемые при программировании на C, предпола- гают, что: 쐽 имена символьных переменных дополняются префиксом c или ch; 쐽 целочисленным индексам присваиваются имена i и j; Перекрестная ссылка Дополне- ние языка конвенцией именова- ния, компенсирующей ограниче- ния самого языка, является при- мером программирования с ис- пользованием языка вместо простого программирования на языке (см. раздел 34.4). 1 Значением передается ссылка на объект, который и может быть изменен. — Прим. перев. 268 ЧАСТЬ III Переменные 쐽 имена переменных, хранящих количество чего-либо, до- полняются префиксом n; 쐽 имена указателей дополняются префиксом p; 쐽 имена строк начинаются с префикса s; 쐽 имена макросов препроцессора включают ТОЛЬКО_ЗАГ- ЛАВНЫЕ_БУКВЫ; обычно это правило распространяется и на имена типов, определяемых при помощи директивы typedef; 쐽 имена переменных и методов включают только_строчные_буквы; 쐽 для разделения слов служит символ подчеркивания (_): имена_такого_вида читаются легче, чем именатакоговида. Эти правила справедливы для программирования на C в общем, а также для сред UNIX и Linux, однако в разных средах конвенции имеют свои особенности. Про- граммисты на C, разрабатывающие программы для Microsoft Windows, предпочи- тают применять для именования переменных ту или иную форму венгерской нотации и буквы верхнего и нижнего регистров. Программисты, разрабатываю- щие ПО для платформы Macintosh, обычно используют для именования методов смешанный регистр, потому что инструментарий Macintosh и методы ОС были изначально разработаны в соответствии с интерфейсом Pascal. Конвенции C++ С программированием на C++ связаны такие конвенции: 쐽 целочисленным индексам присваиваются имена i и j; 쐽 имена указателей дополняются префиксом p; 쐽 имена констант, типов, определяемых с помощью дирек- тивы typedef, и макросов препроцессора включают ТОЛЬКО_- ЗАГЛАВНЫЕ_БУКВЫ; 쐽 имена классов и других типов содержат БуквыОбоихРегистров; 쐽 первое слово в именах переменных и методов начинается со строчной буквы, а все последующие слова — с заглавной: имяПеременнойИлиМетода; 쐽 символ подчеркивания используется только в именах, состоящих полностью из заглавных букв, и после некоторых префиксов (например, после префикса, служащего для идентификации глобальных переменных). Как и в случае языка C, некоторые аспекты этой конвенции могут зависеть от конкретной среды. Конвенции Java В отличие от C и C++ конвенции стиля программирования на Java были сформулированы уже на ранних этапах раз- вития этого языка: 쐽 i и j — имена целочисленных индексов; 쐽 имена констант включают ТОЛЬКО_ЗАГЛАВНЫЕ_БУКВЫ, а слова разделяются символами подчеркивания; Дополнительные сведения Классической книгой о стиле программирования на C являет- ся «C Programming Guidelines» (Plum, 1984). Дополнительные сведения О стиле программирования на C++ см. книгу «The Elements of C++ Style» (Misfeldt, Bumgardner, and Gray, 2004). Дополнительные сведения О сти- ле программирования на Java см. книгу «The Elements of Java Style, 2d ed.» (Vermeulen et al., 2000). |