Программирование. Принципы и практика использования C++ Исправленное издание
вернуться

Страуструп Бьерн
Шрифт:

case '+': case '–': case '*': case '/':

return Token(ch); // пусть каждый символ обозначает сам себя

Этот код был неплох, пока мы не добавили символы

'q'
,
';'
и
'%'
, но теперь он стал непонятным. Код, который трудно читать, часто скрывает ошибки. И конечно, они есть в этом фрагменте! Для их выявления необходимо разместить каждый раздел
case
в отдельной строке и расставить комментарии. Итак, функция
Token_stream::get
принимает следующий вид:

Token Token_stream::get

// считываем символ из потока cin и образуем лексему

{

if (full) { // проверяем, есть ли в потоке хотя бы одна лексема

full=false;

return buffer;

}

char ch;

cin >> ch; // Перевод:" оператор >> игнорирует разделители пробелы,

// переходы на новую строку, табуляцию и пр.)"

switch (ch) {

case quit:

case print:

case '(':

case ')':

case '+':

case '–':

case '*':

case '/':

case '%':

return Token(ch); // пусть каждый символ обозначает сам себя

case '.': // литерал с плавающей точкой может начинаться с точки

case '0': case '1': case '2': case '3': case '4':

case '5': case '6': case '7': case '8': case '9': // числовой

// литерал

{ cin.putback(ch); // возвращаем цифру обратно во входной

// поток

double val;

cin >> val; // считываем число с плавающей точкой

return Token(number,val);

}

default:

error("Неправильная лексема");

}

}

Разумеется, можно было бы поместить в отдельной строке раздел

case
для каждой цифры, но это нисколько не прояснит программу. Кроме того, в этом случае функция
get
вообще осталась бы за пределами экрана. В идеале на экране должны поместиться все функции; очевидно, что ошибку легче скрыть в коде, который находится за пределами экрана. Расположение кода имеет важное значение. Кроме того, обратите внимание на то, что мы заменили простой символ
'q'
символическим именем
quit
. Это повышает читабельность кода и гарантирует появление сообщения компилятора при попытке выбрать для имени
quit
значение, уже связанное с другим именем лексемы.

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

7.6.4. Комментарии

При разработке кода мы включили в него несколько комментариев. Хорошие комментарии — важная часть программирования. В рабочей суматохе мы часто забываем об этом. Момент, когда мы возвращаемся к коду для приведения его в порядок, лучше всего подходит для проверки следующих свойств комментариев.

1. Корректность (вы могли изменить код, оставив старый комментарий).

2. Адекватность (редкое качество).

3. Немногословность (чтобы не отпугнуть читателя).

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

x = b+c; // складываем переменные b и c и присваиваем результат

// переменной x

Такие комментарии часто можно встретить в учебниках, но они нужны лишь для того, чтобы объяснить свойства языка, которые еще не известны читателям. Комментарии нужны для того, чтобы объяснять то, что сложно выразить средствами языка программирования. Примером такой ситуации является выражение намерения программиста: код означает лишь то, что программа делает на самом деле, но он ничего не может сказать читателю о действительных намерениях программиста (см. раздел 5.9.1). Посмотрите на код программы калькулятора. В нем кое-чего не хватает: функции описывают, как мы обрабатываем выражения и лексемы, но ничего не сказано (помимо самого кода) о том, что именно мы считаем выражением и лексемой. Лучше всего поместить такие комментарии в грамматике.