•В C/C++ стиль представления может определять порядок файлов, подключаемых директивой #include. Тут есть разные течения мыс% ли. Одни включают сначала системные файлы, затем файлы проек% та и в конце специфические для данного файла. Другие считают, что надежнее обратный порядок; это предохраняет от зависимости заголовочного файла от заголовков, обычно включаемых перед ним. В некоторых стандартах требуется, чтобы в самих заголовочных файлах отсутствовали #include, а в файлах реализации содержалось длинное перечисление.

Разное

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

5.Что важнее – хорошее представление кода или хорошее проектиро вание кода? Почему?

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

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

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

Вопросы личного характера

1.У вас есть свой постоянный стиль?

a.Работая с чужим кодом, какой стиль вы применяете – авторский или свой?

b.В какой мере ваш стиль кодирования определяется автоматическим форматированием, применяемым в вашем редакторе? Служит ли оно достаточной причиной для принятия определенного стиля?

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

Если вы не в состоянии писать код в одном и том же стиле, ваш диплом программиста следует аннулировать. Если вы не в состоянии повто%

рить стиль представления другого программиста, вас нужно назна% чить сопровождать BASIC на всю оставшуюся жизнь.

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

2.Табуляция – дьявольское изобретение или благо? Объясните.

a.Что вам известно о своем редакторе? Вставляет ли он символы табу ляции автоматически? Какова величина табуляции в вашем редак торе?

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

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

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

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

Вы встретите рекомендации относительно правильного выбора размера табуляции, причем старательно обоснованные. Это все очень хорошо; есть солидное исследование, доказывающее, что три или четыре про% бела обеспечивают лучшие возможности для чтения. (Я предпочитаю четыре пробела, потому что не люблю нечетные числа!) Тем не менее табуляция не должна соответствовать никакому фиксированному ко% личеству пробелов. Табуляция есть табуляция, она не пробел и не крат% на пробелу. Если код структурирован с помощью табуляции, не долж% но иметь никакого значения, сколькими пробелами представляется табуляция – код должен легко читаться в любом случае. К сожалению, мне редко приходилось встречать код с отступами в виде табуляции, который удовлетворял бы этому требованию. Очень часто табуляцию и пробелы смешивают, чтобы выровнять код. Это удается, если табу% ляция установлена так же, как у автора. В остальных случаях возни% кает невообразимый беспорядок.

стиле. Измените его представление согласно своим вкусам. Не касай% тесь существа реализации.

/* Возвращает результат проверки num на простоту.*/ bool

isPrime( int num ) {

for ( int x = 2; x < num; ++x ) {

if ( !( num % x ) ) return false;

}

return true;

}

/* Эта функция вычисляет 'n' е простое число./ int

prime( int pos ) { if ( pos ) {

int x = prime( pos 1 ) + 1; while ( !isPrime( x ) ) {

++x;

}

return x; } else {

return 1;

}

}

Это реальный код, который не нужно воспринимать как глупое и не% интересное упражнение.

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

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

Теперь поглядите на то, что написали.

•Какие отличия у вашей версии? Сколько конкретных изменений вы внесли?

•Для каждой модификации задайте себе вопрос: связана ли она с эс% тетическими предпочтениями или можно найти для нее рациональ% ное обоснование? Проверьте это обоснование – насколько оно вес% ко? Готовы ли вы защищать его?

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

Дайте себе дополнительные очки, если вам захотелось написать код по%другому, сделав его более эффективным, и еще очки, если вы устоя% ли перед таким соблазном. (Преждевременная оптимизация – это по% рочная практика; см. раздел «Технические подробности» на стр. 274.)