Голуб Ален И. - Веревка достаточной длины, чтобы... выстрелить с. Руководство по программированию. Автору удается сделать изложение столь серьезной темы живым и интересным за счет рассыпанного по тексту юмора и глубокого знания предмета
 Скачать 1.36 Mb.
|
|
Часть 4 Имена и идентификаторы Имена играют важную роль. Правильно выбранные имена могут сделать программу поистине самодокументированной, не требуя совсем или требуя мало дополнительного набора в виде явных комментариев. Плохо выбранные имена (например, state — состояние или штат ?) могут добавить ненужную сложность в вашу программу. Эта часть книги содержит правила выбора имен. Форматирование и доку ментация 57 44. Имена должны быть обычными словами английского языка, описывающими то, что делает функция, аргумент или переменная Избегайте аббревиатур; они ухудшают читабельность программ. Некоторые по привычке продолжают использовать аббревиатуры, что приводит к абсурдной практике, типа отбрасывания последней буквы слова или удаления из него всех гласных. Возьмем странно названную функцию UNIX creat() ; очевидно, что create() лучше. Я также видел странности типа lnghth вместо length и mt вместо empty При этом общепринятые аббревиатуры являются очевидными исключениями. Вот тот минимум из них, которым я пользуюсь сам: col — индекс столбца; cur — текущий; i j — обобщенные счетчики циклов; max — максимум (обычно в качестве префикса или суффикса); min — минимум (обычно в качестве префикса или суффикса); obj — обобщенный объект (имеется указатель на базовый класс, но производный класс не известен); p ptr — обобщенный указатель; s str — строка (в языке Си обычно char * ), но не употребляйте их, если называемый объект используется не как обобщенный. Например, i имеет смысл использовать в качестве счетчика цикла в операторе for , если этот счетчик используется просто для подсчета числа итераций: for ( i = 10; --i >= 0; ) // нарисовать 10 тире putchar('-'); Используйте настоящее имя, если вы применяете счетчик для чего-нибудь отличного от счета. Сравните этот код: for ( i = 0; i < imax; ++i ) for ( j = 0; j < jmax; ++j ) move_cursor( i,j ); со следующим: for ( row = 0; row < max_row; ++row ) for ( col = 0; col < max_col; ++col ) move_cursor( row, col ); Я также избегаю использовать x и y вместо row и column . Одно из ранее указанных правил рекомендует пропускать программу через систему проверки орфографии. Действительное достоинство этого метода состоит Правила программирования на Си и Си++ 58 в том, что он побуждает вас использовать в качестве имен обычные слова. 44.1. Не используйте в качестве имен тарабарщину Отличный образец такого подхода можно наблюдать в любом предлагаемом Microsoft примере программы, хотя эта проблема ни в коем случае не ограничивается корпорацией Microsoft. Все демонстрационные программы Microsoft Windows включают тип переменной в ее имя. Например, объявление типа: const char *str; будет сделано следующим образом: LPCSTR lpszstr; Переведите lpszstr как "указатель типа long с именем str на строку, оканчивающуюся 0 ". На самом деле здесь несколько проблем, не последней из которых является тот факт, что LPCSTR скрывает наше объявление указателя. Тем не менее, обсуждаемое правило посвящается проблеме самого имени. Этот стиль выбора имен называется "венгерской" записью по названию родины руководителя отдела программирования Microsoft Чарльза Саймони, который его изобрел. (а не потому, что его использование придает программам Microsoft такой вид, как будто они написаны на венгерском языке.) Венгерская запись целесообразна для языка ассемблера, в котором все, что вы знаете о переменной — это ее размер. Включение информации о типе в имя переменной позволяет вам контролировать правильность ее использования. 2 Языки более высокого уровня типа Си и Си++ используют для этой цели объявление переменных. Доктор Саймони несколько раз в печати защищал такой метод записи, но я бы не стал его рекомендовать для программ на Си или Си++. По моему мнению, венгерская запись не дает ничего, кроме ухудшения читаемости программ. Простые str или string значительно легче читаются и содержат ту же информацию. Если вам на самом деле нужно узнать тип, то для этого достаточно вернуться к определению. 3 2 Я подозреваю, что венгерская запись так интенсивно используется вследствие того, что большая часть Microsoft Windows написана на языке ассемблера. 3 По крайней мере, оно должно быть. Я подозреваю, что некоторые энтузиасты венгерской записи так плохо организуют свои программы, что просто не могут найти нужные объявления. Включая тип в имя, они избавляются от многих часов поисков в неудачно спроектированных листингах. Программы на языке ассемблера, которые по необходимости включают в себя множество глобальных переменных, являются очевидным исключением. Форматирование и доку ментация 59 Существует и более распространенный, хотя и менее радикальный прием, при котором имена указателей начинают символом p. Эта практика тоже загромождает программу. Вы ведь не начинаете имена целочисленных переменных типа int символом i, переменных типа double — d, а функций — f? Очевидным исключением является случай, когда у вас есть объект и указатель на этот объект в одной и той же области видимости: char str[128], *pstr = str; c другой стороны, для указателя, вероятно, лучше содержательное имя. Сравните: char str[128], *first_nonwhite = str; while ( isspace(*first_nonwhite) ) ++first_nonwhite; // В этой ситуации имя *first_nonwhite говорит вам гораздо // больше о том, что делает переменная, чем предыдущее"*pstr". 45. Имена макросов должны записываться ЗАГЛАВНЫМИ_БУКВАМИ Как показывается в последующих разделах, макросы часто вызывают побочные эффекты. Поэтому полезно иметь возможность определить с первого взгляда, что у вас является макросом. Конечно, вы не должны использовать только заглавные буквы для чего-нибудь помимо макросов, иначе вы не достигнете цели данного правила. 45.1. Не используйте заглавных букв для констант перечисления Должна быть обеспечена возможность замены констант, определенных в перечислении, на переменную типа const . Если ее имя записано заглавными буквами, то вам придется его менять. Кроме того, имеются еще и проблемы с макросами (вскоре будут рассмотрены), которых нет у перечислений. Поэтому будет полезно иметь возможность различать их с первого взгляда. 45.2. Не используйте заглавных букв в именах типов, созданных при помощи typedef Так как макрос также может использоваться в манере, подобной typedef , то полезно знать может или нет что-то быть использовано в качестве синтаксически правильного типа. Например, имея: typedef void (*ptr_to_funct)( int ); Правила программирования на Си и Си++ 60 вы можете написать следующее: (ptr_to_funct)( p ); // преобразует p в указатель на функцию ptr_to_funct f( long ); // f возвращает указатель на функцию Макрос типа: #define PTR_TO_FUNCTION void (*) ( int ) позволяет вам сделать преобразование: (PTR_TO_FUNCTION) ( p ); но не позволяет объявить функцию: PTR_TO_FUNCTION f( long ); Указанный макрос при подстановке дает: void (*) ( int ) f( long ); но компилятору нужно: void (*f( long ))( int ); Имя типа из строчных букв не вызовет никаких проблем при чтении, потому что по смыслу вы всегда можете сказать, используется ли оно для типа или нет. 46. Не пользуйтесь именами из стандарта ANSI Cи Идентификаторы, начинающиеся с символа подчеркивания, и имена типов, оканчивающиеся на _t , были зарезервированы стандартом ANSI Cи для использования разработчиками компиляторов. Не используйте эти символы. Также избегайте имен функций, вошедших в стандарт ANSI Cи и в проект стандарта ISO/ANSI для Си++ ♣ 47. Не пользуйтесь именами Microsoft Это может показаться правилом, специфичным только для Microsoft, но на самом деле это не так (учитывая имеющуюся склонность Microsoft к мировому господству). Любой, кто заботится о переносимости, должен рассчитывать на то, что его или ее программа со временем может или работать под управлением операционной системы Microsoft, или взаимодействовать с библиотекой классов Microsoft. Библиотека MFC, например, перенесена на Macintosh и во многие операционные среды ♣ В августе 1998 г. стандарт ратифицирован в виде "ISO/IEC 14882, Standard for the C++ Programming Language". Популярно изложен в книге: Страуструп Б. Язык программирования С++, 3–е изд. /Пер. с англ.—СПб.; М.: "Невский диалект" — "Издательство БИНОМ", 1999.–991 с. — Прим. перев. Форматирование и доку ментация 61 UNIX/Motif на момент написания этой книги, и, вероятно, появится на других операционных системах в ближайшем будущем. На момент написания этой книги интерфейс прикладного программирования Windows (API) включает в себя около 1200 функций. Библиотека MFC, быстро вытесняющая первоначальный интерфейс на языке Си, добавляет около 80 определений классов. К сожалению, метод Microsoft состоит в добавлении каждый раз дополнительных функций и классов в новую версию компилятора. Если Microsoft случайно выберет в качестве имени для функции или класса то, которое вы используете для каких-то других целей, угадайте, кому из вас придется его сменить? Так как ни один из идентификаторов Microsoft не соответствует стандарту ANSI Cи, требующему, чтобы имена поставляемых разработчиком объектов начинались с символа подчеркивания, то вы должны предохраняться, избегая использования соглашений по выбору имен в стиле Microsoft: • Все имена функций Microsoft используют соглашения в стиле Паскаля о СмесиЗаглавныхИСтрочныхБукв() , и они всегда начинаются с заглавной буквы. Я предпочитаю имена только из строчных букв с символами подчеркивания, но что бы вы ни выбрали, НеИспользуйтеСтильMicrosoft() . Функции-члены в классах MFC используют то же самое соглашение. • Все имена классов Microsoft начинаются с заглавной "С" с последующей заглавной буквой (например, CString , CWnd , CDialog и т.д.). Начальная "С" мало что дает, кроме беспорядка, и ее пропуск удаляет нас от области имен Microsoft. • Одна из наиболее фундаментальных заповедей объектно- ориентированного проектирования запрещает оставлять незащищенными данные-члены в определении класса. Тем не менее, многие классы MFC имеют открытые поля данных. Все эти поля начинаются с m_ , не имеющих другого назначения, кроме как увеличить беспорядок. Тем не менее, мы можем использовать эту бессмыслицу для того, чтобы не начинать имена своих собственных полей с m_ и таким образом легко отличать свои члены от унаследованных из базовых классов MFC. Правила программирования на Си и Си++ 62 48. Избегайте ненужных идентификаторов Имена для констант часто вообще не нужны. Например, не определяйте значения, возвращаемые при ошибке; если возвращается всего одна ошибка, возвратите просто FALSE . Не делайте так: enum { INSERT_ERROR, DELETE_ERROR }; insert() { //... return INSERT_ERROR; } delete() { //... return DELETE_ERROR; } а просто возвратите 0 в случае ошибки и в случае успеха любое правильное значение типа 1 49. Именованные константы для булевых величин редко необходимы Выбор неверного имени может добавить значительную ненужную сложность в вашу программу. Рассмотрим следующую простейшую функцию, которая подсчитывает количество слов в строке: int nwords( const char *str) { typedef enum { IN_WORD, BETWEEN_WORDS } wstate; int word_count = 0; wstate state = BETWEEN_WORDS; for (; *str ; ++str ) { if ( isspace(*str) ) state = BETWEEN_WORDS; else if ( state != IN_WORD ) { ++word_count; state = IN_WORD; } } return word_count; } Неправильно выбранное имя state заставило нас ввести два ненужных Форматирование и доку ментация 63 идентификатора: IN_WORD и BETWEEN_WORDS . Теперь взгляните на этот вариант: int nwords2( const char *str) { int word_count = 0; int in_word = 0; for (; *str ; ++str ) { if ( isspace(*str) ) in_word = 0; else if ( !in_word ) { ++word_count; in_word = 1; } } return word_count; } Переименование нечетко названной переменной state во что-нибудь, что действительно описывает назначение переменной, позволило мне исключить булевые именованные константы IN_WORD и BETWEEN_WORDS . Получившаяся подпрограмма меньше и легче читается. Вот другой пример. Следующая программа: enum child_type { I_AM_A_LEFT_CHILD, I_AM_A_RIGHT_CHILD }; struct tnode { child_type position; struct tnode *left, *right; } t; //... t.position = I_AM_LEFT_CHILD; if ( t.position == I_AM_LEFT_CHILD ) //... может быть упрощена подобным образом ♣ : struct tnode { unsigned is_left_child ; struct tnode *left, *right; } t; t.is_left_child = 1; if ( t.is_left_child ) ♣ В стандарте ISO/IEC 14882 существует тип ‘bool’. Имеет смысл заменить тип переменной is_left_child на bool . — Ред. Правила программирования на Си и Си++ 64 //... тем самым исключая два ненужных идентификатора. И вот последний пример: enum { SOME_BEHAVIOR, SOME_OTHER_BEHAVIOR, SOME_THIRD_BEHAVIOR }; f( SOME_BEHAVIOR, x); f( SOME_OTHER_BEHAVIOR, x); f( SOME_THIRD_BEHAVIOR, x); требующий четырех идентификаторов (три именованные константы и имя функции). Лучше, хотя это не всегда возможно, исключить селекторную константу в пользу дополнительных функций: some_behavior(x); some_other_behavior(x); some_third_behavior(x); Обратной стороной этой монеты является вызов функции. Рассмотрим следующий прототип: create_window( int has_border, int is_scrollable, int is_maximized ); Я снова выбрал рациональные имена для исключения необходимости в именованных константах. К сожалению, вызов этой функции плохо читаем: create_window( TRUE, FALSE, TRUE ); Просто взглянув на такой вызов, я не получу никакого представления о том, как будет выглядеть это окно. Несколько именованных констант проясняют обстоятельства в этом вызове: enum { UNBORDERED =0; BORDERED =1}; // Нужно показать значения, enum { UNSCROLLABLE=0; SCROLLABLE =1}; // или create_window() enum { NORMAL_SIZE =0; MAXIMIZED =1}; // не будет работать. //... create_window( BORDERED, UNSCROLLABLE, MAXIMIZED ); но теперь у меня другая проблема. Я не хочу использовать именованные константы внутри самой create_window() . Они здесь только для того, чтобы сделать ее вызов более читаемым, и я не хочу загромождать эту функцию таким кодом, как: if ( has_border == BORDERED ) //... сравнивая его с более простым: if ( has_border ) Форматирование и доку ментация 65 //... Первый вариант уродлив и многословен. К сожалению, если кто-то изменит значение именованной константы BORDERED , второй оператор if не будет работать. Я обычно соглашаюсь с мнением, что программист, занимающийся сопровождением, не должен менять значения идентификаторов, как я это проделал в предыдущем примере. Часть 5 Правила обычного программирования Эта часть содержит правила, относящиеся к написанию собственно исходного текста программы, в отличие от предыдущей части, в которой рассматривалась разработка программы в целом. Эти правила не слишком зависят от выбора языка программирования. Правила обычного программирования 67 50. Не путайте привычность с читаемостью (Или синдром "настоящего программиста, который может программировать на любом языке как на ФОРТРАНе"). Многие люди пытаются злоупотреблять препроцессором для того, чтобы придать Си большее сходство с каким-нибудь другим языком программирования. Например: #define begin { #define end } while ( ... ) begin // ... end Эта практика ничего не дает, кроме того, что ваш код становится нечитаемым для кого-нибудь, кто не знает того языка, который вы стараетесь имитировать. Для программиста на Си код станет менее читаемым, не более того. Родственная проблема связана с использованием макросов препроцессора для скрытия синтаксиса объявлений Си. Например, не делайте следующего: typedef const char *LPCSTR; LPCSTR str; Подобные вещи вызывают проблемы с сопровождением, потому что кто- то, не знакомый с вашими соглашениями, будет должен просматривать typedef , чтобы разобраться, что происходит на самом деле. Дополнительная путаница возникает в Си++, потому что читатель может интерпретировать происходящее, как определение объекта Си++ из класса LPCSTR . Большинству программистов на Си++ не придет в голову, что LPCSTR является указателем. Объявления Си очень легко читаются программистами на Си. (Кстати, не путайте вышеупомянутое с разумной практикой определения типа word в виде 16-битового числа со знаком для преодоления проблемы переносимости, присущей типу int , размер которого не определен ни в ANSI Си, ни в ANSI Си++). К тому же, многие программисты избегают условной операции ( |