Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 11 Сила имен переменных 259 Старайтесь не присваивать переменной статуса имя flag Наоборот, рас# сматривайте флаги как переменные статуса. Имя флага не должно включать фраг# мент flag, потому что он ничего не говорит о сути флага. Ради ясности флагам сле# дует присваивать выразительные значения, которые лучше сравнивать со значени# ями перечислений, именованных констант или глобальных переменных, выступа# ющих в роли именованных констант. Вот примеры неудачных имен флагов: Примеры загадочных флагов (C++) if ( flag ) ... if ( statusFlag & 0x0F ) ... if ( printFlag == 16 ) ... if ( computeFlag == 0 ) ... flag = 0x1; statusFlag = 0x80; printFlag = 16; computeFlag = 0; Команды вида statusFlag = 0x80 будет совершенно непонятны, пока вы не пояс# ните в коде или в документации, что такое statusFlag и 0x80. Вот более понятный эквивалентный фрагмент: Примеры более грамотного использования переменных статуса (C++) if ( dataReady ) ... if ( characterType & PRINTABLE_CHAR ) ... if ( reportType == ReportType_Annual ) ... if ( recalcNeeded == True ) ... dataReady = true; characterType = CONTROL_CHARACTER; reportType = ReportType_Annual; recalcNeeded = false; Очевидно, что команда characterType = CONTROL_CHARACTER выразительнее, чем statusFlag = 0x80. Аналогично условие if ( reportType == ReportType_Annual ) понятнее, чем if ( printFlag == 16 ). Второй фрагмент показывает, что данный подход приме# ним к перечислениям и предопределенным именованным константам. Вот как с помощью именованных констант и перечислений можно было бы задать исполь# зуемые в нашем примере значения: Объявление переменных статуса (C++) // возможные значения переменной CharacterType const int LETTER = 0x01; const int DIGIT = 0x02; const int PUNCTUATION = 0x04; const int LINE_DRAW = 0x08; const int PRINTABLE_CHAR = ( LETTER | DIGIT | PUNCTUATION | LINE_DRAW ); 260 ЧАСТЬ III Переменные const int CONTROL_CHARACTER = 0x80; // возможные значения переменной ReportType enum ReportType { ReportType_Daily, ReportType_Monthly, ReportType_Quarterly, ReportType_Annual, ReportType_All }; Если вам трудно понять какой#то фрагмент кода, подумайте о переименовании переменных. В отличие от детективных романов код программ не должен содер# жать загадок. Его нужно просто читать. Именование временных переменных Временные переменные служат для хранения промежуточных результатов вычис# лений и служебных значений программы. Обычно им присваивают имена temp, x или какие#нибудь другие столь же неопределенные и неописательные имена. В целом использование временных переменных говорит о том, что программист еще не полностью понял проблему. Кроме того, с переменными, официально получившими «временный» статус, программисты обычно обращаются небреж# нее, чем с другими переменными, что повышает вероятность ошибок. Относитесь к «временным» переменным с подозрением Часто значение нуж# но на некоторое время сохранить. Однако в том или ином смысле временными являются почти все переменные. Называя переменную временной, подумайте, до конца ли вы понимаете ее реальную роль. Рассмотрим пример: Пример неинформативного имени «временной» переменной (C++) // Вычисление корней квадратного уравнения. // Предполагается, что дискриминант (b^24*a*c) неотрицателен. temp = sqrt( b^2 4*a*c ); root[0] = ( b + temp ) / ( 2 * a ); root[1] = ( b temp ) / ( 2 * a ); Значение выражения sqrt( b^2 % 4 * a * c ) вполне разумно сохранить в перемен# ной, особенно если учесть, что оно используется позднее. Но имя temp ничего не говорит о роли переменной. Лучше поступить так: Пример замены «временной» переменной на реальную переменную (C++) // Вычисление корней квадратного уравнения. // Предполагается, что дискриминант (b^24*a*c) неотрицателен. discriminant = sqrt( b^2 4*a*c ); root[0] = ( b + discriminant ) / ( 2 * a ); root[1] = ( b discriminant ) / ( 2 * a ); По сути это тот же код, только в нем использована переменная с точным описа# тельным именем. ГЛАВА 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_. |