Вопрос по оформлению кода. Зачем в программах на С++ фигурную скобку принято переносить? Ведь в других языках она остаётся на той же строке - и это компактно, удобно.

Например
- некрасиво. Во многих языках делают так:

Должна быть явная причина... А при желании можно настроить автоформат и перегнать весь проект туда-сюда

методы  форматирования текста разные. И они определяются во вкладе qtcreator "проекты".  Если бы вы бросились не на Qt, а на изучение языка C++, то прочли бы в книгах о способах форматирования исходников.

вложенные блоки легче визуально определить, когда они определены отдельностоящими { и }

Мне импонирует первый вариант.

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

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

Сравни варианты

и второй вариант


В общем я за первый. И ненавижу второй
PS потому что пользуюсь первым!

Для наглядности, советую прикрутить автору голосовалку и проверить приверженность форумчан к какому-то стилю.

Стилей оформления C++ кода много.
К примеру, см. доку Artistic Style.
Если брать исторический тренд, то вначале "{" переносились на новую строку для всех языковых конструкций (Керниган и Ритчи, C), потом возобладали компромиссные варианты (например, Страуструп использует перенос только для методов классов и функций), сейчас, я бы сказал, раскол, некоторые корпорации предпочитают не использовать переносов "{" вообще (см. например Google C++ Style Guide).

В общем, чем сложнее становятся проекты и насыщеннее код модулей (классов, пространств имён), тем предпочтительнее вертикальная компактизация. Особенно когда в сжатые сроки нужно ознакомится с большим объёмом кода. Высокое разрешение монитора и вертикальная ориентация, и свёртка блоков в IDE, конечно сильно помогают, но панацеей не являются.
Я вижу тут пару психологических моментов: Во-первых, код блока (объявления класса, определения функции/метода), зачастую не помещается в пределах экрана, приходится листать туда-обратно, что раздражает само по себе, плюс теряется так называемый темп (оперативная память человека способна удерживать какой-то образ/установку без напряга несколько секунд, потом происходит соскок). Во-вторых, при быстром просмотре глаз "спотыкается" на отдельно стоящих скобках.

У меня сложился стиль оформления, близкий к Google. Единственное, что меня раздражает в их стиле, - чрезмерные отступы при разрыве длинного списка параметров функции, я в таких случаях использую тот же отступ, что и для тела функции, для наглядности префиксируя строки запятыми и перенося "{" на отдельную строку.
К слову, к Google я не испытываю никакого пиетета.

Это если в сфероконных условиях (от "сферический конь в вакууме" ).
В реальности под напором сенсорных образов - ты же ведь не над одной строчкой кода медитируешь - образ размывается очень быстро: взгляд мотнулся вверх-вниз, зацепил непроизвольно соседние блоки, при прокрутке метнулся (бессознательно) за изменившимся бегунком, если для навигации по модулю используется "Class view" или "Outline", перескочил на соответствующую панель... и всё, наблюдаем картину Репина "Приплыли" - старые образы начинают затираться, и нужно прикладывать специальное усилие, чтобы сконцентрироваться на нужном.
Объём же кратковременной памяти составляет 4-5 однотипных единиц (кстати, вовсе не 3-9, как считалось ранее, пример с телефонным номером не показатель, поскольку единицей там является группа цифр, которая запоминается как отдельный глиф).


Ну мы же не беллетристику читаем, типа "прочитал и тут же забыл" . Какая эффективность усвоения этих пятисот страниц?... Как бы не вышло, что околонулевая... Это если говорить о технической литературе. А если о коде, то всё ещё сложнее, поскольку линейное (без мысленного прохода по стеку возможных вызовов и по иерархиям классов) и монотонное (без остановок на осмысление) прочтение - это вообще nonsense. Лимитирующим фактором тут будет не скорость визуального восприятия, а скорость осмысления.

И не надо давить цифрами.
С быстрочтением я ознакомился ещё в начале восьмидесятых, до сих пор на полке лежит препринт книги с дарственной надписью автора (Хромов Лев Николаевич).
Так что представление о его возможностях и недостатках имею достаточное.


По мне - как раз наоборот.
Но зависит от индивидуальных особенностей восприятия человека.
Если стиль мышления больше синтетический (нисходящий, от высших абстракций к низшим) и "препроцессор" успевает на лету структурировать зрительный образ, то достаточно использования отступов по глубине вложенности.  Перенос открывающей скобки только запутывает. Для иллюстрации: вот у тебя есть дерево (допустим, файловой системы), в котором часть пунктов  - в одну строку, а часть - в две, воспринимать дерево стало же сложнее, правильно?!...

PS. Насчёт "говнокода", я этот термин вообще не употребляю. Хотя бы потому, что хороший код - это вообще исключение.

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

А на счёт голосования - я вижу, что всё-таки с большим отрывом перевесил пункт "везде переносить {". И я приму его как свой личный стандарт форматирования кода, хотя до этого придерживался совсем противоположного мнения.

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