go home();

34. Указывайте имена аргументов в прототипах функций

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

some function( int, int, int, int, int );

то вам не удастся получить много помощи.

35. Используйте предикатную форму при разбиении длинных выражений

Предикатом в английском языке называется вторая половина предложения - глагол и дополнение, над которым глагол выполняет действие. Порядок слов в английском предложении, конечно, фиксированный: глагол всегда идет первым.

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

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

if( its thursday and the moon is in scorpio()

its friday afternoon and close to quitting time() i just cant bear to look at this computer for another minute(

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

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

if( its thursday and the moon is in scorpio()

its friday afternoon and close to quitting time()

i just cant bear to look at this computer for another minute())

go home();

36. Подпрограмма должна помещаться на экране

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

Вообще, мне нравится, когда рабочая часть подпрограммы (ее текст, в меньшей степени комментарии заголовка и так далее) видна полностью при редактировании; она должна целиком помещаться на экране или в окне.

37. Нужно обеспечивать возможность распечатки всего текста программы

Часто проще найти ошибку на распечатанной странице, чем на экране, даже на большом. Текст на бумаге легче читается вследствие более высокого разрешения и лучшего фокусного расстояния, чем на экране. При этом вы можете разложить бумажные распечатки по всей поверхности стола. Вы вряд ли чем-нибудь сможете заменить бумагу в этом плане, если только у вас нет монитора с диагональю полтора метра и разрешением 300 точек на дюйм.

Итак, ваша программа должна легко печататься. Подпрограммы должны помещаться по возможности на одной странице (не более 60 строк), и ни одна строка программы не должна быть такой длины, чтобы не поместиться в строку распечатки (около 79 символов, в зависимости от

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

---------------------------------------------------------void descriptive name( type descriptive name )

Если имена функции и аргументов недостаточно содержа тельны, то я помещаю здесь комментарий, описывающий, что она делает. Я опускаю этот комментарий, если имена достаточно понятны. (Соответствующее правило гласит: Не объясняй очевидного ).

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

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

code goes here();

шрифта), даже если ваш текстовый редактор поддерживает скроллинг по горизонтали. Если вы выйдете за эти пределы, то будете вынуждены использовать столь мелкий шрифт для вывода, что совсем не сможете прочитать свою распечатку.

38. Используйте штриховую линию для зрительного разделения подпрограмм

Я всегда ставлю такой комментарий:

---------------------------------------------------------над каждым определением функции. (И к тому же, я не использую штриховую линию нигде более). Хотя пустые строки замечательно подходят для зрительного разделения блоков программы, исключительно их использование не дает эффекта. Штриховая линия между функциями облегчает их поиск. Так же как пустая строка указывает на границу абзаца, штриховые линии подобны заголовкам разделов. Если мне нужно еще более четкое разделение, то я использую:

==========================================================

=========== =====