14-й час

Стиль *

программирования: Что такое хорошо, и что такое плохо

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

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

Задача написания удобного для чтения, стилистически грамотного кода одинаково

важна как для программиста-любителя, в одиночку корпящего над выстраданной проблемой, так и для профессионала, работающего в коллективе единомышленников над

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

Ниже рассказывается о приемах и соглашениях, которые помогут вам продлить

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

Основные темы занятия.

Соглашения об именовании объектов программы.

Отступы и комментарии - средства обеспечения удобочитаемости текста.

Как упростить код и обеспечить его повторное использование.

Советы по тестированию и отладке кода.

Соглашения об именах

Степень удобства восприятия программного текста во многом зависит от качеств

принятой системы именования объектов. Если говорить об объеме работы по вводу

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

Существует два подхода к вопросу о том, что представляет собой правильная система именования объектов программы. Обе точки зрения привлекают внимание определенных кругов приверженцев. Одна из школ отстаивает мнение о полезности системы, основанной на так называемой префиксной нотации, или, как ее часто называют, венгерской нотации. Такая концепция была предложена в начале 80-х Шарлем Симони (Charles Simonyi). Венгерская нотация предполагает разработку и использование системы префиксов, в сокращенной форме описывающих принадлежность переменных, объектов, функций и процедур определенному типу. Например, буква i может быть поставлена в соответствие типу integer, и тогда названию каждого объекта кода и данных, который имеет отношение к целочисленному типу, должен предшествовать символ i. Так, например, переменную типа Integer, предназначенную для хранения данных о возрасте человека, следовало бы назвать iAge. Можно привести и другие примеры с подробными пояснениями.

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

Новый термин

Новый термин

Строго типизированный язык программирования не допускает неточностей в отношении трактовки типов переменных. Все значения должны обязательно соответствовать оговоренным типам переменных. Примером строго типизированного языка служит C++. VBA также можно отнести к строго типизированным языкам, хотя и не в такой степени строгим , как большинство реализаций C++.

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