Стиль кода: фигурные скобки

[MihalNik]

Не первый и не второй{
____а Python'овский стиль во всех языках
____}
Ошибок с ними не возникало очень давно, да и не нужно их читать повторно в коде.
Особенно доставляют претензии к громоздкости дельфийских begin... end -
также практически не замечаю их в своем коде.

Переключаться всегда на чужой, непродуманный стиль ("стиль одного какого-то языка или фреймворка") - глупо.

Сообщение от Alex11223

Так кроме фигурных скобок еще есть:
а) обычные скобки (ставить ли пробелы, как переносить когда много аргументов)
б) имена функций/методов
в) имена классов
г) имена переменных
д) имена свойств
е) имена полей
ё) имена констант
ж) имена файлов, количество классов на файл
з) имена неймспейсов
и) имена интерфейсов
й) имена Exception'ов
к) TABы vs пробелы
л) количество пустых строк между методами, классами, ...
м) порядок имен в #include/using/import
н) порядок членов класса: сначала свойства, потом методы, или наоборот?
о) и public сначала или private?
п) а конструкторы куда? Сверху? Снизу?
р) а this писать при любых обращениях к членам класса?
с) else (в if {... } else { ... }) на одной строке с закрывающей скобкой if'a или на следующей
т) пробелы рядом с операторами (=, ==, +, -, *, /, mod, ...)
у) документирование, комментарии, xmldoc, type-hinting и т.д.
ф) длинные логические выражения как переносить? a && b && c ... && z — && ставить на новой строке или оставлять на предыдушей?
х) макс. длина строк
ц-∞) специфеское для языка, паттерна (mvc/mvvm/...), фреймворка

а) визуальная декомпозиция практически всегда однозначна,
если порядок зрительно расчленения кода не соответствует исполняемому - быдлокод
б..й) имена должны быть понятными, остальное не важно:
дублирование имен параметров/свойств/методов - это недостатки языка/фреймворка,
поэтому надо делать так, как в нем принято разработчиками.
к) косяки ИДЕ
л) более одной - глупо.
м, н) не имеет значения, не заморачиваясь, в порядке появления необходимости подключения.
о) сначала private (вообще несущественно, т.к. ИДЕ должна уметь сворачивать такие разделы, т.е. косяк разработчиков)
к) конструкторы впереди (кроме о)
p) нафиг не писать по-возможности ни this не const - это паранойя
с) просто глупость
т) очевидно f= a*b + c/d; (см. а)
у) по-минимуму
ф) см. а.
ц) см. исходные примеры фрейворка.

[IT-Lopata]

2-й вариант удобнее
тоже как писал феникс юзаю http://ru.wikipedia.org/wiki/CamelCase

[pompiduskus]

Я за Первый вариант ! Так привык.

Есть такаие моменты где вы просто НЕ СМОЖЕТЕ использовать первый вариант, иначе будут ошибки !

[MaTBeu]

Сообщение от pompiduskus

Я за Первый вариант ! Так привык.

Есть такаие моменты где вы просто НЕ СМОЖЕТЕ использовать первый вариант, иначе будут ошибки !

Обьясните, что за моменты и в каких языках случаются?

[Alex11223]

В JS если написать что-то типа

return
{
    something: 'value'
};

то будет return undefined (ну как будто return; ).

[pompiduskus]

Сообщение от Alex11223

В JS если написать что-то типа

return
{
    something: 'value'
};

то будет return undefined (ну как будто return; ).

Да я как раз про этот случай !

[alexinspir]

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

Если в компании требуют форматировать код - шлите такую компанию подальше - там не код пишут, а полной хернёй страдают. красота кода не в его форматировании, а в алгоритме. В таких компаниях нет и никогда не будет перспектив - в техническом руководстве люди недостаточно квалифицированные, которые верят в серебряные пули и которым срать на качество, и вместо того чтобы делать свою работу, они создают лишь видимость работы и лячкают красивые отчеты более высокому руководству.

у меня был опыт в одной такой компании, называется кацит (kacit.ru). Там даже за отсутствие нужного числа вайтспейсов[больше, меньше] вызывали на ковер. Для полноты картины добавлю, что там стало так не сразу - в самом начале существования компании там было супер и работа реально была в кайф (никакой херни небыло), даже хотелось задерживаться до поздна, что собственно многие и делали, хоть и не получали за это нихрена (при этом сами зарплаты очень низкие - разработчик уровня ~wizard получал 50к (2012г), а годовые премии на столько смешные, что их мона не учитывать вообще).

//p.s. инфа о компании добавлена для гуглящих инфу о будущем месте работы

[vasek123]

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

p.s. Я, еще, например, привык делать отступы после операторов присваивания, математических операторов, и т.д., и т.п., однако, если кто то пишет иначе то, даже слова не говорю...

[Utkin]

Хм... Не вижу особого смысла в данной теме.

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

Если в компании требуют форматировать код - шлите такую компанию подальше - там не код пишут, а полной хернёй страдают. красота кода не в его форматировании, а в алгоритме.

Злоупотребление конечно выдает некомпетентность руководящего состава с головой. Однако, минимальный набор требований имеет свойство быть и чем крупней фирма тем необходимей документ подобного рода. Цель его - всех писать "как надо", а не привязывать к одному стилю.

Там даже за отсутствие нужного числа вайтспейсов[больше, меньше] вызывали на ковер.

С дури можно и х** сломать. Тут явный неадекват.

[Kostia]

Настройте уже у себя автоформатирование и не парьте людям мозги

Если в компании требуют форматировать код - шлите такую компанию подальше - там не код пишут, а полной хернёй страдают. красота кода не в его форматировании, а в алгоритме.

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