OberonCore

не согласен. приведёт к размазыванию текстов на большое число строк

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

Я на одной строке пишу операции, которые логически являются атомарными. Копипаста их не нарушит.

Это не проблема копипасты, а проблема восприятия.

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

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

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

Кстати, нередко наблюдаю ситуацию, когда искажается суть размещённого в интернете кода после копирования в редактор.

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

А подробней можно?

"Много где" ещё не означает что так надо везде и это лучший вариант. А ещё много где производительность измеряется числом строк...

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

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

Аналогично с пошаговым отладчиком и установкой BreakPoint'ов. Шаг отладчика = 1 строке. Если у нас в одной строке IF ELSE END, то не видно, какая ветка отработала. Или на каком из цепочки операторов вылетело исключение, не говоря уж о промежуточных значениях переменных.

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

Производительность числом строк кода за единицу времени давно уже не меряют. Даже у индусов-аутсорсеров.

Везде безусловно не надо. Например в книжках не надо. Но в промышленном коде обычно надо.

Справедливости ради, это не везде так. Кое-где шаг это таки операция (при этом в коде подсвечивается ровно тот текст который соответствует текущему шагу). Это удобно в том числе когда у нас есть нечто вроде:

А чем меряют? Я не в теме просто.

В закрытых CR (Client Request). При этом каждый CR оценивается в часах (менеджеры и разработчики как-то сторговываются с заказчиком во сколько часов данный CR оценивается).

По сути в конце концов смотрится на сколько часов закрыто CR'ок за единицу времени (например неделю).

Это ровном счётом проблемы, вызыванные спецификой отладчика и сравнителя текстов. Т.е. получается, что в данном случае требование писать один оператор в одну строку прежде всего диктуется спецификой инструмента.

Специфика восприятия, по-моему, в деталях субъективна. Понятно, что если писать всё в одну строку, то не понятно будет всем. Однако каждый оператор на одной строке, это, кажется, скорее детали. Раньше я тоже с трудом разбирал по паре операторов в строке, т.к. привык к одному. Теперь же наоборот, у меня восприятие буксует, если несколько простых операторов размазаны на отдельные строки...

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

В частности необходимость лепить пачку операторов на одной строке частенько идет из за специфики такого инструмента как "бумажная книга", которая не имеет таких элементарных функций, как например полнотекстовый поиск, отображение одновременно более чем двух страниц и т.п. Да что там, она даже свертку кода (aka folding) не умеет!

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

Скажем, в ЯП без сборки мусора передачу объекта на владение делаю следующим образом:
A := B; B := NIL;
Удаление объекта из списка:
TObject(List[i]).Free; List[i] := NIL;
Кое-где конструкции, возможно, и избыточны, но уменьшают вероятность ошибок работы с памятью.
А вот чтение некоторых обероновских исходников режет глаза, так как привык к блочному коду с элементарными операциями и if ... else ... в одной строке считаю если не варварством, то для многих программистов нечитаемым точно.