Брайан в. Керниган

Роб Пайк

1. Стиль

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

Вильям Странк, Элвин Б. Уайт. Элементы стиля

Приводимый фрагмент кода взят из большой программы, написанной много лет назад:

if ( (country == SING) || (country == BRNI) ||

(country == POL) || (country == ITALY) )

{

/*

* если страна - Сингапур, Бруней или Польша,

* то временем ответа является текущее время,

* а не время, передаваемое в параметре.

* Переустанавливается время ответа

* и задается день недели.

*/

......

Этот фрагмент тщательно написан, форматирован и комментирован, а программа, из которой он взят, работает предельно корректно; про­граммисты, написавшие ее, по праву гордятся своим творением. Одна­ко для постороннего глаза этот фрагмент все же представляется стран­новатым. По какому принципу объединены Сингапур, Бруней, Польша и Италия? И почему Италия не упомянута в комментариях? Код и ком­ментарий не совпадают, так что один из них неверен. Не исключено, что неверны и оба. Правда, код все же исполнялся и тестировался, так что, скорее всего, он верен, а комментарий просто забыли обновить вместе с кодом. Комментарий не объясняет, что общего у перечисленных в нем стран, хотя эта информация будет просто необходима, если вам придет­ся заниматься поддержкой этого кода.

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

Начнем мы с непривычного — с обсуждения стиля в программирова­нии. Чем лучше у вас стиль, тем проще читать ваши программы вам са­мим и другим программистам; хороший стиль просто необходим для хо­рошего программиста. Мы начинаем со стиля, чтобы в дальнейшем вы обращали на него внимание во всех примерах.

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

Принципы хорошего стиля программирования состоят вовсе не в на­боре каких-то обязательных правил, а в здравом смысле, исходящем из опыта. Код должен быть прост и понятен: очевидная логика, есте­ственные выражения, использование соглашений, принятых в языке разработки, осмысленные имена, аккуратное форматирование, развер­нутые комментарии, а также отсутствие хитрых трюков и необычных конструкций. Логичность и связность необходимы, потому что другим будет проще читать код, написанный вами, а вам, соответственно, — их код, если все будут использовать один и тот же стиль. Детали могут быть продиктованы местными соглашениями, требованиями менедж­мента или самой программой, но даже если это не так, то лучше всего подчиняться наиболее распространенным соглашениям. Мы в своем повествовании будем придерживаться стиля, использованного в книге "Язык программирования С" с некоторыми поправками для C++ и Java.

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

Для того чтобы вы могли без труда отличить хорошие примеры от плохих, мы будем начинать строки сомнительного кода со знака вопро­са, как, например, в этом фрагменте (помните — все фрагменты взяты из реальных программ):

? #define ONE 1

? #define TEN 10

? #define TWENTY 20

Что может быть спорным в этих макроопределениях? А вы представьте себе изменения, которые необходимо будет внести в программу, если массив из TWENTY (двадцати) элементов понадобится увеличить. Нужно по меньшей мере заменить все имена на более осмысленные, указываю­щие на роль данного значения в программе:

#define INPUT_MODE 1

#define INPUT_BUFSIZE 10

#define OUTPUT_BUFSIZE 20