Найти среднее арифметическое значение массива

Стив Макконнелл "Совершенный код" (31 глава, стр. 742)

Размещение одного оператора на строке

Современные языки, такие как C++ и Java, позволяют располагать несколько операторов на одной строке. Однако когда дело касается этого вопроса, мощь свободного форматирования оборачивается палкой о двух концах. Следующая строка содержит несколько выражений, которые, с точки зрения логики, вполне могут располагаться в отдельных строках:
Аргументом в защиту размещения нескольких выражений на одной строке может служить факт, что в этом случае требуется меньшее число строк экранного пространства или бумаги для распечатки, что позволяет одновременно видеть больший объем кода. Это также позволяет сгруппировать взаимосвязанные выражения, а некоторые программисты даже полагают, что так они подсказывают компилятору, как можно оптимизировать код.
Все так, но основания для самоограничения, требующие оставлять не более одного оператора в строке, гораздо серьезней.

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

В C++ избегайте выполнения нескольких операций в одной строке (побочные эффекты)
Побочные эффекты — это последствия выполнения некоторого выражения, проявляющиеся в дополнение к основным результатам выполнения этого выражения. Так, в C++ оператор ++, расположенный на одной строке с другими операторами, приводит к проявлению побочного эффекта. Присваивание значения переменной и применение левой части этого присваивания в условном операторе также является примером побочного эффекта.
Побочные эффекты снижают читаемость кода. Например, если n равно 4, что напечатает выражение, приведенное в листинге 31-48?

Листинг 31-48. Пример непредсказуемого побочного эффекта (C++)
4 и 6? Или 5 и 7? А может, 5 и 6? Правильный ответ: «Ни то, ни другое и не третье». Первый аргумент —++n — равен 5. Но язык C++ не определяет порядок вычисления условий выражения или аргументов функции. Поэтому компилятор может вычислить второй аргумент, n + 2, либо до, либо после первого аргумента, и результат может быть равен 6 или 7 в зависимости от компилятора. В листинге 31-49 показано, как переписать это выражение, чтобы прояснить свои намерения:

Листинг 31-49. Пример избавления от непредсказуемого побочного эффекта (C++)
Если вы все еще не совсем уверены в том, что побочные эффекты надо выносить в отдельные строки, попробуйте понять, что делает функция, приводимая в листинге 31-50:

Листинг 31-50. Пример слишком большого количества операции в строке (C)
Некоторые опытные программисты не видят сложности в этом примере, потому что эта функция им знакома. Они смотрят на нее и говорят: «Это функция strcpy()». Однако в нашем случае это не совсем strcpy(). Она содержит ошибку. Если вы сказали «Это strcpy()», увидев данный код, вы узнали код, а не прочитали его. В такую же ситуацию вы попадаете при отладке программы: код, на который вы не обратили внимания, потому что «узнали», а не прочли его, может содержать ошибку, поиск которой займет гораздо больше времени, чем она этого заслуживает.
Фрагмент, показанный в листинге 31-51, функционально идентичен первому варианту и гораздо удобней для чтения:

Листинг 31-51. Пример читаемого количества операций в каждой строке (C)
В этом переформатированном коде ошибка очевидна. Конечно, t и s инкрементируются до того, как *s будет скопирована в *t. Первый символ пропускается.
Второй пример выглядит продуманней первого, хотя операции, выполняемые во втором примере, идентичны первому. Причина такого впечатления в том, что во втором варианте не скрывается сложность выполняемых действий.
Рост производительности также не оправдывает размещения нескольких операций на одной строке. Поскольку обе функции strcpy() логически эквивалентны, можно ожидать, что компилятор сгенерирует для них идентичный код. Однако при профилировании обеих функций выяснилось, что для копирования 5 000 000 строк первой функции понадобилось 4,81 секунды, а второй —4,35.
В нашем случае «умная» версия показала снижение скорости на 11%, что делает ее гораздо менее умной. Результаты могут изменяться от компилятора к компилятору, но в целом они свидетельствуют о том, что пока вы не измерили прирост производительности, следует сначала стремиться к ясности и корректности, а уж затем — к производительности.
Даже если вы легко читаете выражения с побочными эффектами, пожалейте тех, кому придется разбираться с вашим кодом. Большинству программистов нужно дважды подумать, чтобы понять выражения с побочными эффектами. Позвольте им использовать мозговые клетки для осмысления более общих вопросов работы вашего кода, а не синтаксических деталей конкретного выражения.