Зачем '{' переносить на следующую строку?

[yarick]

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

Например

Код:

MyClass::myFunc()
{
//code
}

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

Код:

MyClass::myFunc(){
//code
}

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

[_OLEGator_]

Зачем люди используют желтый цвет в одежде? - Да нравится им желтый цвет!
Лично я предпочитаю как раз первый вариант оформления кода.

[maint]

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

[Figaro]

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

[Alex Custov]

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

[kambala]

кому-то может быть жалко лишней строчки. лично я использую второй вариант.

[Bepec]

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

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

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

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

Код:

fludfasdfd;
fasflud;
fludfd;
bla bla;
if(bla < blaBla && bla !=0 && bla < 999999)
{
    tirik;
    if (bla < blaBpl)
    {
        ddd;
        aaa;
        fff;
    }
    turik;
}
flud;

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

Код:

fludfasdfd;
fasflud;
fludfd;
bla bla;
if(bla < blaBla && bla !=0 && bla < 999999){
    tirik;
    if (bla < blaBpl){
        ddd;
        aaa;
        fff;
    }
    turik;
}
flud;

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

[kambala]

ой, я имел в виду первый

[_OLEGator_]

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

[kuzulis]

Но тут надо отделить мух от котлет. Имею ввиду скобочки в выражениях и скобочки в функциях/методах.

Для выражений - второй вариант
Для методов - первый вариант

[tester64]

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

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

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

[Bepec]

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

К тому же на "чтение" влияет так же скорость чтения отдельного человека. С моим "книгу в 500 страниц за час" довольно легко держать в памяти пару классов.

Тут ещё вопрос проектов. К примеру проект с скобками на новых строках понимается легче из-за четкого разделения блоков кода  

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

PPS те кто буду кричать - автоформатирование, куча прог для этого и прочее - я беру ситуацию аля "посмотри пожалуйста мой код, что тут не так прямо сейчас", а не "посмотри пожалуйста мой код, когда дойдёшь домой, включишь комп, проведёшь полный его анализ и автоформатирование"

PPPS ой на демагогию меня потянуло. Ппц.

 

[tester64]

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

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

К тому же на "чтение" влияет так же скорость чтения отдельного человека. С моим "книгу в 500 страниц за час" довольно легко держать в памяти пару классов.

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

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

Тут ещё вопрос проектов. К примеру проект с скобками на новых строках понимается легче из-за четкого разделения блоков кода

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

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

[Bepec]

Мои 500 страниц = запоминание смысла, запоминание ключевых моментов, которые позволяют восстановить всю последовательность событий

Но не буду спорить. Ваше сообщение больше. Будьте довольны

[yarick]

Стилей оформления C++ кода много.
К примеру, см. доку Artistic Style.

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

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

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