Следует избегать лишних проверок условий. Например:

if ( а < b ) с - 1; else if ( а > b ) с = 2;

else if ( а == b ) с = 3:

Вместо этих операторов можно написать:

if ( а < b ) с = 1: else if ( а > b ) с = 2: else с = 3;

Пли даже так: с = 3:

if ( а < b ) с = 1; if ( а > b ) с - 2;

Если первая ветвь оператора i f обеспечивает передачу управления, использовать зетвъ else нет необходимости:

if ( i > 0 ) break:

здесь i <= О

3 некоторых случаях условная операция лучше условного оператора:

if ( z == 0 ) i = j; else i = k; лучше так: i = z == 0 ? j : k;

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

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

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

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

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

Совсем хорошо, если они при этом не будут содержать орфографических ошибок.

пытаться оптимизировать все, что попадается под руку , поскольку главных принцип программиста тот же, что и врача: Не навреди! . Если программа ра ботает недостаточно эффективно, надо в первую очередь подумать о том, каки< алгоритмы в нее заложены.

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

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

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

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

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

string but = qwerty ; double ex = 3.1234; int number = 12; byte z =0;

if ( done ) Console.WriteLine! Сумма ряда - + у ); else Console.WriteLineC Ряд расходится ):

if ( x>= 0 && x <10 ) у = t * x;

else if ( x >= 10 ) у = 2 * t:

else у = x;

Рекомендации по программированию 99

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

Абзацный отступ комментария должен соответствовать отступу комментируемого блока:

II Комментарий, описывающий, что происходит в следующем ниже блоке программы, { /* Непонятный блок

программы */

Для разделения методов и других логически законченных фрагментов пользуйтесь пустыми строками или комментарием вида

------------

Не следует размещать в одной строке много операторов. Как и в русском языке, после знаков препинания должны использоваться пробелы:

f = a + b; плохо! Лучше f - а + Ь;

Помечайте конец длинного составного оператора, например: while ( true ) {

while ( х < у ) {

fo r ( i = 0; i < 10; + + i ) {

for(j = 0;j<10; + + j ) {

} две страницы код end fo r ( j = 0; j < 10; + + j ) } end for ( i = 0; i < 10; + + i )

} II end while ( x < у )

} end while ( true )

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

В заключение порекомендую тем, кто предпочитает учиться программированию не только на своих ошибках, очень полезные книги [2], [6].

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