CHAP2-4 (1018803), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

void descriptive_name( type descriptive_name )

{

// Если имена функции и аргументов недостаточно содержа-

// тельны, то я помещаю здесь комментарий, описывающий,

// что она делает. Я опускаю этот комментарий, если имена

// достаточно понятны. (Соответствующее правило гласит:

// "Не объясняй очевидного").

//

// Затем я описываю возвращаемое значение и аргумент.

// И вновь вы можете не использовать комментарий, если

// имена достаточно удачные.

//

// Наконец, я помещаю здесь комментарий, описывающий, как

// функция делает то, что она делает. И снова я пропускаю

// этот комментарий, если программа сама по себе доста

// точно содержательна.

code_goes_here();

}

39. Пробел - один из наиболее эффективных комментариев.

Это кажется мелочью, но это может чрезвычайно улучшить читаемость вашей программы. Обратите внимание, как используются пробелы в этой книге в качестве организующего средства, и вы поймете, как использовать их в своей собственной программе. Пустые строки (или отступ в первой строке) зрительно разделяют абзацы. Пробел следует за точкой, но не должен ей предшествовать, потому что точка завершает что-либо. Вы получили идею. А вот правила:

• Разбивайте текст программы на логические куски (т.е. абзацы), где каждый кусок выполняет одну операцию. Окружите эти куски или пустыми строками, или строками с фигурными скобками.

• За знаком препинания всегда должен идти пробел.

• Операторы являются сокращениями слов. Когда вы видите "+", то говорите "плюс". Подобно любому сокращению, вы должны окружать идентификатор пробелами. (Например: a + b читается "a плюс b", a+b читается "aплюсb").

• Исключение составляют унарные операторы, которые рассматриваются как словарные префиксы или суффиксы (*p,a--,f(arg,arg), и т.д.).

• . или -> в С/С++ являются эквивалентом символа подчеркивания. До и после них пробелов быть не должно: p->msg(), obj.msg().

Вот пример того, что может произойти, когда вы что-нибудь упаковываете слишком плотно. Рассмотрим:

int *p;

y=(x/*p++);

f(int /* place-holder */);

Если вы удалите комментарии, то получите:

int *p;

y=(x

);

Сочетание /* в выражении y=(x/*p++) расценивается как символ начала комментария, который заканчивается сочетанием */ в вызове функции f(). (Такой случай действительно со мной произошел, и мне потребовался целый день, чтобы в нем разобраться. Естественно, компилятор не давал сообщений об ошибках, потому что здесь все синтаксически правильно).

Еще замечание по данному поводу. Мне часто приходилось позднее видеть объявления подобные следующему:

int* x;

Проблема состоит в том, что:

int* x, y;

не объявляет два указателя, как подсказывает распределение пробелов. Здесь мы имеем на самом деле еще одну проблему из рода "я могу на любом языке программирования писать как на ФОРТРАНЕ". Было бы прекрасно, если бы С работал также, как подсказывает предыдущее форматирование, но это не так. После правильного форматирования

int *x, y;

становится совершенно ясно, что x - указатель, а y - нет.

40. Используйте отступы в четыре пробела.

Никлас Вирт, который изобрел языки Паскаль и Модула-2, однажды выпустил книгу, где всюду использовались отступы в один символ. Чтение листингов из нее представляло одно из самых тяжелых случаев в моей практике. Используйте достаточно большие отступы, чтобы ваш читатель мог сказать, что в тексте видно абзацы; четыре пробела кажутся идеальными.

Вы должны делать отступы последовательно. Даже во внешнем блоке подпрограммы должны быть отступы. Такой вариант не приемлем:

void f(void)

{

if ( x )

yyy();

more_cod();

even_more_code();

}

потому что слишком трудно найти начало подпрограммы. Сравните предыдущий вариант со следующим:

void f(void)

{

if ( x )

yyy();

more_cod();

even_more_code();

}

41. Условные операторы выделяются абзацными отступами.

Я делаю это даже в операторах из одной строки:

if ( by_land )

one();

else

two();

а не так:

if ( by_land ) one() else two();

Очевидным исключением является:

if ( by_land )

{

one();

}

else if ( by_sea )

{

two();

}

else if ( by_air )

{

three();

}

Я использовал здесь скобки по двум причинам. Во-первых, я как-то попал внутрь условного оператора при отладке и забыл вставить скобки, как в следующем тексте:

if ( by_land )

one(); if(debug) printf("aagh");

else if ( by_sea )

что привело привело фактически к:

if ( by_land )

one();

if (debug)

printf("aagh");

else

if ( by_sea )

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

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

if ( by_land ) one();

else if ( by_sea ) two();

else if ( by_tunnel ) three();

но это нечитаемо:

if (by_land)one();

else if(by_sea)two();

else if(by_tunnel)three();

Подобный код никуда не годится:

for ( a ; b ; c );

while ( ++i < 10 );

Слишком просто случайно сделать следующее:

while ( i < 10 );

++i;

(Другими словами, "вечно сравнивать i с 10, затем увеличить i"). Если точка с запятой никогда не ставится в конце строки, на

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

41.1. Комментарии должны иметь тот же отступ, что и окружающий текст программы.

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

f()

{ /* Здесь идет

** длинный комментарий

*/

code();

}

Здесь имеется сходная проблема:

f()

{

int local_var;

int another_local_var;

code();

}

Отсутствие отступа при определении локальных переменных заставляет предположить, что они находятся в той же области видимости, что имя функции (которая является глобальной). Так как это не так, то вы должны сделать отступ, чтобы указать на область видимости:

f()

{

int local_var;

int another_local_var;

code();

}

42. Выравнивайте скобки вертикально по левой границе.

Иногда поиск отсутствующей фигурной скобки превращается в крупную проблему. Если вы вынесете скобки туда, где их хорошо видно, то их отсутствие будет сразу же заметно:

while ( some_condition )

{

// внутренний блок

}

Я в самом деле не люблю так называемый стиль Кэрнигана и Ричи:

if ( condition {

code();

}else{

more_code();

}

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

43. Используйте скобки, если в условном операторе имеется более, чем одна строка.

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

if ( something() )

{

/* Quo usque tandem abutere

* Gatesalina, patientia

* nostra^* .

*/

somethig_else();

}

Глава

4

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

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

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

Избегайте аббревиатур; они ухудшают читабельность программ. Некоторые по привычке продолжают использовать аббревиатуры, что приводит к абсурдной практике, типа отбрасывания последней буквы слова или удаления из него всех гласных. Возьмем странно названную функцию UNIX creat(); очевидно, что create() лучше. Я также видел странности типа lnghth вместо length и mt вместо empty.

При этом общепринятые аббревиатуры являются очевидными исключениями. Вот тот минимум из них, которым я пользуюсь сам:

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

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

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

Существует и более распространенный, хотя и менее радикальный прием, при котором имена указателей начинают символом p. Эта практика тоже загромождает программу. Вы ведь не начинаете имена целочисленных переменных типа int символом i, переменных типа double - d, а функций - f? Очевидным исключением является случай, когда у вас есть объект и указатель на этот объект в одной и той же области видимости:

char str[128], *pstr = str;

c другой стороны, для указателя, вероятно, лучше содержательное имя. Сравните:

char str[128], *first_nonwhite = str;

while ( isspace(*first_nonwhite) )

Характеристики

Список файлов книги