Правила программирования на Си и Си++ Ален И. Голуб




Название Правила программирования на Си и Си++ Ален И. Голуб
страница 4/19
Дата публикации 19.06.2014
Размер 3 Mb.
Тип Реферат
literature-edu.ru > Авто-ремонт > Реферат
1   2   3   4   5   6   7   8   9   ...   19
Часть

4

Имена и идентификаторы

Имена играют важную роль. Правильно выбранные имена могут сделать программу поистине самодокументированной, не требуя совсем или требуя мало дополнительного набора в виде явных комментариев. Плохо выбранные имена (например, state — состояние или штат ?) могут добавить ненужную сложность в вашу программу. Эта часть книги содержит правила выбора имен.

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. Одно из ранее указанных правил рекомендует пропускать программу через систему проверки орфографии. Действительное достоинство этого метода состоит в том, что он побуждает вас использовать в качестве имен обычные слова.

44.1. Не используйте в качестве имен тарабарщину

Отличный образец такого подхода можно наблюдать в любом предлагаемом Microsoft примере программы, хотя эта проблема ни в коем случае не ограничивается корпорацией Microsoft. Все демонстрационные программы Microsoft Windows включают тип переменной в ее имя. Например, объявление типа:

const char *str;

будет сделано следующим образом:

LPCSTR lpszstr;

Переведите lpszstr как "указатель типа long с именем str на строку, оканчивающуюся 0". На самом деле здесь несколько проблем, не последней из которых является тот факт, что LPCSTR скрывает наше объявление указателя. Тем не менее, обсуждаемое правило посвящается проблеме самого имени.

Этот стиль выбора имен называется "венгерской" записью по названию родины руководителя отдела программирования Microsoft Чарльза Саймони, который его изобрел. (а не потому, что его использование придает программам Microsoft такой вид, как будто они написаны на венгерском языке.)

Венгерская запись целесообразна для языка ассемблера, в котором все, что вы знаете о переменной — это ее размер. Включение информации о типе в имя переменной позволяет вам контролировать правильность ее использования.2 Языки более высокого уровня типа Си и Си++ используют для этой цели объявление переменных.

Доктор Саймони несколько раз в печати защищал такой метод записи, но я бы не стал его рекомендовать для программ на Си или Си++. По моему мнению, венгерская запись не дает ничего, кроме ухудшения читаемости программ. Простые str или string значительно легче читаются и содержат ту же информацию. Если вам на самом деле нужно узнать тип, то для этого достаточно вернуться к определению.3

Существует и более распространенный, хотя и менее радикальный прием, при котором имена указателей начинают символом 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 );

вы можете написать следующее:

(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 и во многие операционные среды 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.

    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 заставило нас ввести два ненужных идентификатора: 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 )

    //...

    тем самым исключая два ненужных идентификатора. И вот последний пример:

    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 )

    //...

    Первый вариант уродлив и многословен. К сожалению, если кто-то изменит значение именованной константы BORDERED, второй оператор if не будет работать. Я обычно соглашаюсь с мнением, что программист, занимающийся сопровождением, не должен менять значения идентификаторов, как я это проделал в предыдущем примере.

    Часть

    5

    Правила обычного программирования

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

    50. Не путайте привычность с читаемостью

    (Или синдром "настоящего программиста, который может программировать на любом языке как на ФОРТРАНе"). Многие люди пытаются злоупотреблять препроцессором для того, чтобы придать Си большее сходство с каким-нибудь другим языком программирования. Например:
1   2   3   4   5   6   7   8   9   ...   19

Похожие:

Правила программирования на Си и Си++ Ален И. Голуб icon Основы информатики и вычислительной техники системы программирования
Рассматриваются основные понятия языков программирования. Излагаются процедурный и объектный подходы в программировании. Более подробно...
Правила программирования на Си и Си++ Ален И. Голуб icon Рабочая программа по курсу «основы Программирования на языке ассемблер»
Программа предназначена для обучения основам программирования на языке низкого уровня Ассемблере учащихся средних школ, учреждений...
Правила программирования на Си и Си++ Ален И. Голуб icon Конспект лекций доцента и. А. Волковой по курсу «системы программирования»
Система программирования – комплекс программных инструментов и библиотек, который поддерживает создание и существование программного...
Правила программирования на Си и Си++ Ален И. Голуб icon Практикум на ЭВМ технология программирования в среде С++
Трунов К. В., Рыков В. И. Методы и технологии С++. Технология программирования в среде С++. /Издание Башкирского ун-та. Уфа 2007....
Правила программирования на Си и Си++ Ален И. Голуб icon Гигиенические требования к условиям обучения в общеобразовательных...
Настоящие Санитарно-эпидемиологические правила(далее — Санитарные правила) направлены на предотвращение неблагоприятного воздействия...
Правила программирования на Си и Си++ Ален И. Голуб icon Среда программирования Visual C++ 0 Общий вид окна
Совокупность средств и правил для представления алгоритма в виде пригодном для выполнения вычислительной машиной называется языком...
Правила программирования на Си и Си++ Ален И. Голуб icon Обоснование выбора средств и методов разработки
На данный момент существует огромное множество языков программирования с помощью которых можно написать данную дипломную работу....
Правила программирования на Си и Си++ Ален И. Голуб icon Учебно-методический комплекс по дисциплине «Технологии программирования»
Техническое задание по разработке дизайнерского проекта приложения «умк – учебно-методический комплекс по дисциплине «Технологии...
Правила программирования на Си и Си++ Ален И. Голуб icon Создание диалектов языков программирования с использованием грамматических аспектов
Такие языки называют диалектами. Диалекты языков программирования встречаются довольно часто: практически каждая субд использует...
Правила программирования на Си и Си++ Ален И. Голуб icon Календарно тематическое планирование по литературному чтению 2 класс
...
Литература


При копировании материала укажите ссылку © 2015
контакты
literature-edu.ru
Поиск на сайте

Главная страница  Литература  Доклады  Рефераты  Курсовая работа  Лекции