Здравствуйте, korzh.pavel, Вы писали:

AA>>Писать надо так, как команда договорилась.

KP>я и пишу ибо не охота внутри компании из-за такой мелочи шум поднимать.

Это хорошо. Теперь понаблюдай за собой и обрати внимание на то, как через 2 недели ты привыкнешь и тебе этот вариант станет нравится больше.

AA>>Какая разница, где скобки ставить?

KP>Вот действительно. Какая разница?
KP>Тогда я не понимаю почему из-за такой мелочи программистов надо отвлекать от работы,
KP>чтобы они приучались скобки ставить по новому.

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

Если же ты пришел в уже сложившуюся команду и тебе "навязывают" принятый там стиль кодирования — нужно его просто принять и все. Лично для меня одно из самых приятных ощущений, когда я смотрю на командный код и не помню я его написал или нет. Он выглядит Одинаково и его писала Команда.

AA>>А всяких сопротивляющихся и втихую продолжающих писать по-своему — гнать из команды надо. Чтобы микроклимат не портили...

KP>слишком катигорично.

Здравствуйте, korzh.pavel, Вы писали:

KP>а я только здесь спорю, на rsdn.

KP>просто очень сложно заставить себя делать не логичные вещи.
KP>Ну вот не вижу я логики в этом:
KP>

KP>if (flag) {
KP>  //...
KP>}
KP>

Я не вижу тут ничего нелогичного. Просто стиль такой. На вопрос "что делать, если условие занимает несколько строк — как визуально отделить тело от условия" Икс процентов респондентов ответили "у вас слишком длинные условия — разбейте их на более простые", Игрек процентов — "поставьте 2 отступа для второй и последующих строчек условия", Зет процентов — "оставьте все условие на одной строке, и хрен с ним, что строка получается 200 символов".

Весь Linux Kernel написан в этом стиле — они еще не знают, что они нелогичные. Предлагаю написать на LKML предложение заменить стиль для всех скобок. Меня только в CC не ставьте, пожалуйста.

AA>>Давайте еще размер табуляции обсудим, и нужно или нет табуляцию на пробелы заменять.

KP>можно обсудить.
KP>Кстати тоже холиварная тема, здесь, помоему, уже обсуждалось. Тоже флейм не хилый был

Я, пожалуй, воздержусь от этого обсуждения.

Здравствуйте, Erop, Вы писали:

E>Просто, но это для меня слишком умно. Лучше покажи как оформляешь случай с тремя альтернативами?

Сколько можно повторять — не бывает такого. Три альтернативы из условной компиляции — это, как говорят в Одессе, что-то особенного. Это можно допустить при определениии типа данных, но мне ни разу не приходилось делать ничего подобного для разного кода. И вообще, в моем исходном примере — один-единственный #ifdef, даже безо всякого #else — то есть, либо оно есть, либо его нет. И никаких #else тоже не бывает, не говоря уже о "трех вариантах". На что ты тут начал мощно вопить про "ужас ужас". А проблема-то не стоит и яичной скорлупы. Короче говоря, тебя не должен беспокоить пустяковый вопрос сопровождения и поддержки приведенного решения.

Здравствуйте, korzh.pavel, Вы писали:

KP>Могу только посочувствовать.
KP>Меня тут пытаются заставить писать вот так:
KP>

KP>if (...) {
KP>  //...
KP>}
KP>

KP>так я прям сопротивляюсь всеми фибрами души.

http://geosoft.no/development/index.html

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, korzh.pavel, Вы писали:

KP>>в первом случае условие визуально сливается с телом условия, во втором же — визуально всё разделено и лично мне приятнее читать второй вариант

E>Ты уж прости, но это к психотерапевту надо обратиться или к окулисту, уж даже и не знаю к кому.
E>ИМХО совершенно одинаково читабельно...

К кодооформопатолгоанатомотерапевту.

Но я открывающие скобки переношу. На новую строку переношу.

Здравствуйте, korzh.pavel, Вы писали:
KP>Меня тут пытаются заставить писать вот так:
KP>

KP>if (...) {
KP>  //...
KP>}
KP>

KP>так я прям сопротивляюсь всеми фибрами души.
Не знаю насколько по теме, но на Python-е именно так пишут. Например, Python25\Lib\getopt.py:

if args[0][:2] == '--':
    opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
elif args[0][:1] == '-':
    opts, args = do_shorts(opts, args[0][1:], shortopts, args[1:])
else:
    if all_options_first:
        prog_args += args
        break
    else:
        prog_args.append(args[0])
        args = args[1:]

Здравствуйте, McSeem2, Вы писали:

MS>Сколько можно повторять — не бывает такого. Три альтернативы из условной компиляции — это, как говорят в Одессе, что-то особенного. Это можно допустить при определениии типа данных, но мне ни разу не приходилось делать ничего подобного для разного кода. И вообще, в моем исходном примере — один-единственный #ifdef, даже безо всякого #else — то есть, либо оно есть, либо его нет. И никаких #else тоже не бывает,

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

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

Здравствуйте, Sm0ke, Вы писали:

S>Но я открывающие скобки переношу. На новую строку переношу.
А мне без разницы.
Мало того, я знаю контору, где в некоторых конструкциях обязывают то или иное поведение, а в некоторых предоставляют свободу выбора программисту

KP>Меня тут пытаются заставить писать вот так:
KP>

KP>if (...) {
KP>  //...
KP>}
KP>

Я вот раньше терпеть не мог такого стиля — условие и скобка на одной строчке. А недавно попробовал, привык. Теперь бесит код, где открывающая скобка начинает строку Привычка — великое дело. ИМХО, главное, чтобы программист писал код, качественный с точки зрения выбранной парадигмы и средств языка. А уж как там скобки ставить или классы именовать — дело десятое.

E>Но главное -- это то, что интересностьработы программера и его уровеньопределяется вовсе и не CS, а качеством кода...

согласен. CS здесь не причем

E>А к CS привыкаешь за день-два-три...

главное, чтоб мышка хорошо ездила...