hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Установкаm		стандарта
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
65Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

случаев такой вариант трудноосуществим, особенно если вы регуляр% но получаете все новые и новые файлы из одного источника.

Придерживайтесь стиля полученного файла или проекта либо стиля вашей фирмы в тех случаях, когда между ними нет противоречий, а собственными предпочтениями пожертвуйте. Однако не отказывай% тесь бездумно от своего стиля: взвесьте преимущества и недостатки од% ного и другого. А если в вашей компании нет внутреннего стандарта? Добейтесь, чтобы он был…

Установка стандарта

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

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

Сложность задачи зависит от особенностей членов вашего коллектива:

•Сколько всего программистов

•Как каждый в отдельности пишет код

•Насколько схожи между собой их стили программирования

•Заинтересованы ли они в наличии стандарта

•Готовы ли они к тому, чтобы изменить свой стиль

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

Зачем это нужно?

Начните с уяснения объема предстоящей работы. На кого рассчи% тан будущий стандарт – на отдельную группу, подразделение ком% пании или всю компанию в целом? От этого в большой степени за% висит разработка и реализация.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								66m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 2. Тонкий расчетClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Запомните: то, что хорошо для одного, не обязательно окажется лучшим стилем для группы программистов в целом. Разрабатывае% мые вами рекомендации нацелены не на удовлетворение ваших личных эстетических потребностей, а на то, чтобы стать стандар% том кода, разрабатываемого целой группой, и облегчить взаимодей% ствие в ней. Не упускайте это из виду, когда будете работать над стандартом.

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

Добейтесь поддержки

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

•Прежде чем начать работу над стандартом, убедите всех в его не% обходимости. Постарайтесь объяснить всем преимущества еди% ного стиля кода и неприятности, связанные с его отсутствием.

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

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

Создайте итоговый документ

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

Введите в стандарт лучшее из практики

Отразите в стандарте лучшие из уже существующих в команде тех% нологий – подтвердите людям, что они на правильном пути. Когда в стандарте нет ничего неожиданного, его легче принять. Если же включить в него произвольные положения, не связанные с сущест% вующей практикой, они встретят сопротивление.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Установкаm		стандарта
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
67Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Сосредоточьтесь на существенном

Сконцентрируйте свои усилия на том, что действительно важно и что позволит в наибольшей мере усовершенствовать выпускаемый ва% шей командой код. Не занимайтесь разработкой стандартов пред% ставления для C, C++ и Java, если вы пользуетесь в своей работе только C.

Избегайте опасных конфликтов

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

Не будьте слишком строги: иногда нарушение правил может быть вполне оправданным.

Действуйте поэтапно

Разумно создавать внутрифирменный стиль по частям. Для начала договоритесь о расстановке скобок и отступах – всего лишь. Даже этого добиться будет нелегко! Решив этот вопрос, двигаться дальше уже значительно легче; все остальные нововведения будут пример% но в том же духе. В какой%то момент, когда код станет достаточно упорядоченным, можно прекратить придумывать новые правила.

Планируйте принятие

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

Не запугивайте стандартом и не вводите наказаний за отход от него. Это обычно плохо воспринимается. Лучше придумайте меры поощ% рения – хотя бы в виде похвалы при рецензировании кода.

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

Не правда ли, похоже на то, как уговаривают группу детей не ссорить% ся и вести себя прилично? В результате после преодоления всех религи% озных противоречий у вас на руках будет фирменный стандарт, кото% рый действительно окажет положительное влияние на качество выпус% каемого вами кода. Когда стихнут обиды, вы не пожалеете о содеянном.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								68m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Религиозные войны?

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 2. Тонкий расчетClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Скорейший способ закончить войну – это проиграть ее.

Джордж Орвелл

Вести религиозные войны по поводу форматирования кода – пустая трата времени; есть гораздо более важные проблемы, заслуживающие вашего внимания. Но будьте осторожны: формат кода – не единствен% ное больное место у программистов. Помимо него существуют выбор редактора, компилятора, методологии, Настоящего языка1 и т. д.

Эти мелкие столкновения длятся годами. И будут происходить дальше. И победителя никогда не будет. Никто никогда не даст правильный от% вет, потому что его не существует. Эти споры просто дают возможность одним людям попытаться навязать свое личное (тщательно сформиро% ванное) мнение другим, и наоборот. В конечном счете, мое мнение не мо# жет не быть правильным, потому что оно – мое. Это все равно что пы% таться связать вместе макаронины – какое%то время забавно, но потом надоедает и совершенно бессмысленно. Обычно этим делом грешат не вполне зрелые программисты. (Ветераны уже выдохлись в этих спорах.)

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

Скажи «нет» религиозным войнам. Не вступай в них. Отойди в сторону.

Резюме

Ничто так не способствует успеху, как видимость успеха.

Кристофер Лаш

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

1На память приходит конференция по программированию на C/C++, участ% ником которой я был несколько лет назад. Докладчик поделился своим от% крытием, что применение Pascal вместо C приводит к снижению количест% ва ошибок (и облегчению их исправления), а труднее всего для исправле% ния и многочисленнее ошибки при работе в C++. Реакция была замеча%

тельной – всеобщее возмущение!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Резюмеm
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
69Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Кто еще хочет подраться?

Формат кода – не единственный повод для сражений между про% граммистами. Есть много религиозных вопросов, от которых лучше тактично уклоняться, сберегая свое здоровье. Остерегай% тесь таких тем, как:

Моя ОС лучше твоей

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

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

Мой редактор лучше твоего

…потому что он распознает миллион разных синтаксических систем, может редактировать файлы, написанные иероглифа% ми, а любую из его 400 команд можно выполнить, нажав од% новременно не более 10 клавиш. С ним можно работать на столе, из командной строки, через модем или электропровод% ку, а также замаскировавшись 128%разрядным шифром.

А мой все равно лучше, потому что встраивается в трусы и зна% ет, что я хочу напечатать, еще до того, как я сам это пойму.

Мой язык лучше, чем твой

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

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

Логично предположить, что тщательно структурированный код столь же тщательно спроектирован. С еще большей уверенностью можно утверждать, что неряшливо оформленный код и продуман был доста% точно небрежно. Но дело не ограничивается способом форматирования исходного кода.

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								70m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 2. Тонкий расчетClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

тепла). Да, у вас есть свое мнение, и вы готовы отстаивать его и изла% гать свои взгляды, но не ставьте себе целью победить или доказать свою правоту, как не пытайтесь высокомерно продолжать действовать по%своему.

Хорошие программисты…

•Избегают бессмысленных спо% ров и учитывают чужое мнение

•Достаточно скромны, чтобы по% нимать, что не всегда бывают правы

•Понимают значение формата кода для его удобочитаемости и стремятся писать как можно более понятный код

•Перейдут на корпоративный стиль, даже если он противоре% чит их личным представлениям

Плохие программисты…

•Обладают ограниченным круго% зором и упрямы: только моя точка зрения правильна

•Вступают в спор со всяким и по всякому поводу; для них это спо% соб показать свое превосходство

•Не выработали своего личного устойчивого стиля кодирования

•Переделывают чужой код в соб% ственном стиле

См. также

Глава 3. Что в имени тебе моем?

Стандарт кодирования может определять способ образования имен.

Глава 4. Литературоведение

Хорошее представление – ключ к написанию самодокументирую% щегося кода.

Глава 5. Заметки на полях

Описываются способы написания комментариев; комментарии мо% гут быть связаны с форматом кода.