Kernighan & Richie coding style today - C/C++

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

MZ>Вот, работаю в комании, где практикуют чистый С и
MZ>Kernighan & Richie coding style впридачу.

MZ>Комментарии — только /* */,
MZ>объявления переменных — только в начале функций или блоков,
MZ>ну и прочие прелести. В общем, чтобы на самом старом компиляторе
MZ>можно было бы собрать.

MZ>Насколько оправдан такой подход сейчас ?
MZ>Мне казалось, что GCC уже прошелся победным маршем по всем
MZ>возможным платформам и такое сейчас просто не оправдано.

MZ>(я уже не говорю о использовании С++ вместо С).

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

if (...) {
  //...
}

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

MZ>Вот, работаю в комании, где практикуют чистый С и
Круть!

Давно мечтал сходить в музей по программированию!
MZ>Kernighan & Richie coding style впридачу.
главное чтоб он был, а какой неважно

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

MZ>Мне казалось, что GCC уже прошелся победным маршем по всем
MZ>возможным платформам и такое сейчас просто не оправдано.

У нас похожий подход применяется. С комментариями, правда, попроще

А обусловлено тем, что все-таки не для всех target-платформ есть компилятор gcc C, не говоя уже о g++.

MZ>Вот, работаю в комании, где практикуют чистый С и
MZ>Kernighan & Richie coding style впридачу.
....
Так писали и до сих пор пишут в Microsoft.
Можете посмотреть исходники свежайшего драйвера FAT.

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

MZ>Вот, работаю в комании, где практикуют чистый С и
MZ>Kernighan & Richie coding style впридачу.

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

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

D>Все зависит от задачи. Во-первых, С пошустрее, а уж если С++ коряво используемый, так и гораздо пошустрее.
Крайне спорно
D>Во-вторых, программу гораздо легче читать, если переменные описаны в начале блока, это уж зависит от привычек, но я так и на С# сейчас пишу.
ИМХО, наоборот тяжелее.

Здравствуйте, Аноним, Вы писали:

D>>Во-вторых, программу гораздо легче читать, если переменные описаны в начале блока, это уж зависит от привычек, но я так и на С# сейчас пишу.
А>ИМХО, наоборот тяжелее.

Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

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

ДД>Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

ДД>>Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

KP>так же спорный вопрос. функция больше 15-20 строчек уже не совсем желательна.

Зависит от того, в какой среде разработка ведется и какие требования к оформлению кода. Я стараюсь придерживаться такого правила: функция должна занимать не более 3/4 высоты редактора и содержать не более 3 вложенных конструкций.

korzh.pavel пишет:

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

Ага, вот так и пишем

Это какой-то там древний BSD -convention — :-!

Posted via RSDN NNTP Server 2.1 beta

ДимДимыч пишет:
> А обусловлено тем, что все-таки не для всех target-платформ есть
> компилятор gcc C, не говоя уже о g++.

Пример можешь привести ?

Posted via RSDN NNTP Server 2.1 beta

dimavs пишет:

> используемый, так и гораздо пошустрее. Во-вторых, программу гораздо
> легче читать, если переменные описаны в начале блока, это уж зависит от
> привычек, но я так и на С# сейчас пишу.

Это от привычек не зависит. Программу легче читать, если переменная
объявляется в месте первого использования. Ты знаешь, сколько
у нас тут НЕИСПОЛЬЗУЕМЫХ ПЕРЕМЕННЫХ ?

Posted via RSDN NNTP Server 2.1 beta

ДимДимыч пишет:
> Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

Функции у нас бывают по 1000-1500 строк.

Posted via RSDN NNTP Server 2.1 beta

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

MZ>Насколько оправдан такой подход сейчас ?

Кодинг-стайл — это кодинг-стайл. Не нравится — обращайтесь к старшему. Но следовать ему — must have. Иначе будет ситуация сродни автодорогам: есть ПДД, но каждый ездит по понятиям. А они у каждого свои, вот и уносит по 30 тыщ в год на кладбище.

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

MZ>Функции у нас бывают по 1000-1500 строк.

в совокупности с объявлением переменных в начале это мега

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

MZ>ДимДимыч пишет:
>> Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

MZ>Функции у нас бывают по 1000-1500 строк.

а вот это гораздо хуже объявлений всех переменных в начале блока и комментариев /* */

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

>> А обусловлено тем, что все-таки не для всех target-платформ есть
>> компилятор gcc C, не говоя уже о g++.

MZ>Пример можешь привести ?

С которыми сталкивался лично: PIC18FXX2, 8086.

ДимДимыч пишет:

> С которыми сталкивался лично: PIC18FXX2, 8086.

Можно поподробнее ?
На счет 8086 — все понятно, но не верю, что они еще остались.
Остались ? И что там за ОС ? ДОС ? И нет GCC под дос ?

Posted via RSDN NNTP Server 2.1 beta

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

MZ>Ага, вот так и пишем

MZ>Это какой-то там древний BSD -convention — :-!

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

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

KP>так же спорный вопрос. функция больше 15-20 строчек уже не совсем желательна.

Короткие функции — не самоцель. Целью является грамотная функциональная декомпозиция без значительного ущерба для производительности. Но искусственно разбивать функции, абы-как, только чтобы вписаться в 15-20 строчек — это бред.

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

MZ>На счет 8086 — все понятно, но не верю, что они еще остались.

Сами процессоры 80386, но работают в реальном режиме.

MZ>Остались ? И что там за ОС ? ДОС ?

Никакого ДОСа нет, все ПО свое (сбор и анализ информации с датчиков).

MZ> И нет GCC под дос ?

Есть, но очень сырая и экспериментальная.

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

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

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

вбив бы гадов!

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

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

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

А хочется как?

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

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

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

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

I>А хочется как?

а хочется вот так:

  if (...)
  {
    //...
  }

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

KP>а хочется вот так:

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

Понятно. Думал, ты чего-нибудь необыкновенного захотел, вроде:

  if (...) {
    //... }

А так IMHO зря тебя заставляли, если ты своего любимого стиля последовательно придерживался. Но все же, так, как заставляли, написаны примеры в стандарте C, C++, C#, и в книгах K&R, Страуструпа, Гослинга и Хейлсберга.

Здравствуйте, ДимДимыч, Вы писали:
ДД>Функции стоит делать не диннее чем на ~50 строчек, тогда нормально все

ээх,... все бы этого придерживались. Я тут недавно раскручивал функцию на 2000 строк в файле длиной около 11 тыс строк. Чистый Си, причем объявления функций должны быть в двух видах и старом(K&R) и новом (ANSI). Типа так:

#ifdef NOANSI
static void function(p1,p2,p3)
  int p1;
  int p2;
  int p3;
#else
static void function(int p1,int p2,int p3)
#endif

По другому нельзя,нельзя даже на макросы заменить

Жуть...
Вот где кунцкамера программирования. :-o

ДимДимыч пишет:

> Никакого ДОСа нет, все ПО свое (сбор и анализ информации с датчиков).

Вряд ли тогда там бы нужна была наша СУБД. Она как минимум CRTL требует.

Posted via RSDN NNTP Server 2.1 beta

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

MZ>Вот, работаю в комании, где практикуют чистый С и
MZ>Kernighan & Richie coding style впридачу.

УЖОС!!! Беги оттуда!!! Как ты вообще терпишь?

Вообще-то cs есть cs, а K&R вовсе и не лохи были...
ИМХО соблюдение cs вообще несущественная часть процесса программирования, в смысле по трудозатратам, а вот несоблюдение -- очень существенная может получиться

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

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

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

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

KP>так я прям сопротивляюсь всеми фибрами души.
А что так?
Слишком много текста на экран убирается?
Попробуй увеличить шрифт

Ну а если серьёзно, то если тебе на новом месте не нравится только то, где скобочку почле if надо писать, то тебе парень очень крупно повезло.

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

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

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

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

Это ж кто у нас там такой любитель?

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

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

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

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

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

CS>Это ж кто у нас там такой любитель?

PKv

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

I>А так IMHO зря тебя заставляли, если ты своего любимого стиля последовательно придерживался. Но все же, так, как заставляли, написаны примеры в стандарте C, C++, C#, и в книгах K&R, Страуструпа, Гослинга и Хейлсберга.
ИМХО банально строки экономили. Вариант с открывающей скобкой на отдельной строке куда более читабельный.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>ИМХО банально строки экономили. Вариант с открывающей скобкой на отдельной строке куда более читабельный.

ИМХО пофиг. Просто вопрос привычки быть может.
Можешь попробовать привести пример кода, где "перерасстановка скобок" существенно меняет его понятность

ИМХО обычно всё как у Крылова: "А вы, друзья, как не расставть скобки..."

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

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

CC>>ИМХО банально строки экономили. Вариант с открывающей скобкой на отдельной строке куда более читабельный.

E>ИМХО пофиг. Просто вопрос привычки быть может.
E>Можешь попробовать привести пример кода, где "перерасстановка скобок" существенно меняет его понятность

E>ИМХО обычно всё как у Крылова: "А вы, друзья, как не расставть скобки..."

  if (flag) {
    do_something();
  }

  if (flag) 
  {
    do_something();
  }

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

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

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

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

CC>>>ИМХО банально строки экономили. Вариант с открывающей скобкой на отдельной строке куда более читабельный.

E>>ИМХО пофиг. Просто вопрос привычки быть может.
E>>Можешь попробовать привести пример кода, где "перерасстановка скобок" существенно меняет его понятность

E>>ИМХО обычно всё как у Крылова: "А вы, друзья, как не расставть скобки..."

KP>

KP>  if (flag) {
KP>    do_something();
KP>  }
KP>

KP>

KP>  if (flag) 
KP>  {
KP>    do_something();
KP>  }
KP>

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

И вообще, я могу жить с любой нотацией, мне воротит только от трёх вещей, когда пишешь на C++:

1. Венгерская нотация

2. Имена классов начинающееся с 'C'

3. Когда фигурную скобку ставят на одной строке с условием.

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

KP>И вообще, я могу жить с любой нотацией, мне воротит только от трёх вещей, когда пишешь на C++:

KP>3. Когда фигурную скобку ставят на одной строке с условием.

попрограмь на tcl и этот комплекс пройдет.

Здравствуйте, Аноним, Вы писали:

D>>Во-вторых, программу гораздо легче читать, если переменные описаны в начале блока, это уж зависит от привычек, но я так и на С# сейчас пишу.
А>ИМХО, наоборот тяжелее.

Я вообще привык все используемые переменные определять в начале фукнции, каждую на отдельной строчке, и обязательно инициализировать начальными значениями, например так:

BOOL flag = FALSE;      // флаг
CMyStruct* data = NULL; // расчетные данные
int i = -1;             // счетчик

И мне нравится, и мне так гораздо удобнее. Я думаю, это вопрос привычки...

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

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

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

ИМХО совершенно одинаково читабельно...

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

E>Можешь попробовать привести пример кода, где "перерасстановка скобок" существенно меняет его понятность :)

1.

if(someQuiteLongCondition0 ||
    someQuiteLongCondition1) {
    doSomething();
}

if(someQuiteLongCondition0 ||
    someQuiteLongCondition1)
{
    doSomething();
}

                doSomething();
                doSomething();
                doSomething();
            }

Это что за блок заканчивается? Двигаем курсор на скобку, жмем клавишу «найти парную скобку». Видим:

iteLongCondition0 ||
uiteLongCondition1) {

И?

Кстати, интересно, умеет ли VA или подобные утилиты показывать всплывающие подсказки при наведении мыши на «}».

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

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

Этот вопрос не должен тебя беспокоить.

E>ИМХО совершенно одинаково читабельно...

Не в читаемости дело. Вот гляди (пример для C99):

if(condition) // Есть If
{
    int i = action();
    . . .
}

//if(condition) // Нет If-а (режим отладки)
{
    int i = action();
    . . .
}

Не говоря уже об условной компиляции. Вот пример из реального проекта:

    gv->GlyphParam    = param;
    gv->Glyph         = 0;
    gv->Texture       = 0;
    gv->TextureWidth  = 0;
    gv->TextureHeight = 0;
#ifdef GFC_USE_TEXTURE_GLYPHS
    TextureGlyphData* tgData = param.Font->GetTextureGlyphData();
    if (tgData)
    {
        const TextureGlyph& tg = tgData->GetTextureGlyph(param.GlyphIndex);
        ImageInfoBase* image = tg.GetImageInfo(param.Font->GetBinding());
        if (image)
        {
            gv->Texture       = image->GetTexture(context.GetRenderer());
            gv->TextureWidth  = image->GetWidth();
            gv->TextureHeight = image->GetHeight();
        }
    }
    else
#endif
    {
        gv->Glyph = Cache.GetGlyph(context.GetRenderer(), 
                                   param, 
                                   shape, 
                                   gv->FontSize, 
                                   context.Log);
        if (gv->Glyph)
        {
            gv->Texture = Cache.GetGlyphTexture(gv->Glyph);
            Cache.LockGlyph(gv->Glyph);
        }
    }

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

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

E>>Можешь попробовать привести пример кода, где "перерасстановка скобок" существенно меняет его понятность

RO>1.
RO>

RO>if(someQuiteLongCondition0 ||
RO>    someQuiteLongCondition1) {
RO>    doSomething();
RO>}
RO>

RO>

RO>if(someQuiteLongCondition0 ||
RO>    someQuiteLongCondition1)
RO>{
RO>    doSomething();
RO>}
RO>

RO>2.
RO>

RO>                doSomething();
RO>                doSomething();
RO>                doSomething();
RO>            }
RO>

RO>Это что за блок заканчивается? Двигаем курсор на скобку, жмем клавишу «найти парную скобку». Видим:
RO>

RO>iteLongCondition0 ||
RO>uiteLongCondition1) {
RO>

RO>И?

Отлично. У тебя получилось лучше аргументировать чем у меня.
Как раз недавно разбирал код с такими конструкциями:

  if (someQuiteLongCondition0 ||
      someQuiteLongCondition1 ||
      someQuiteLongCondition2) {
      doSomething1();
      doSomething2();
      doSomething3();
  }

ну невозможно же читать такое!

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

MS>

MS>if(condition) // Есть If
MS>{
MS>    int i = action();
MS>    . . .
MS>}

MS>//if(condition) // Нет If-а (режим отладки)
MS>{
MS>    int i = action();
MS>    . . .
MS>}
MS>

Да уж, мегарежим

А с else ты что делаешь?

Не говоря уже о том, что эту "правку" можно ещё и забыть откатить...

Я тебе советую так делать, кстати:

static bool debugFlag = false;
if( debugFlag || ... ) 
{
    int i = action();
    . . .

}

и сбрасывать debugFlag из отладчика, например, или ещё из каких настроек...

MS>Не говоря уже об условной компиляции. Вот пример из реального проекта:
MS>

    gv->GlyphParam    = param;
    gv->Glyph         = 0;
    gv->Texture       = 0;
    gv->TextureWidth  = 0;
    gv->TextureHeight = 0;
#ifdef GFC_USE_TEXTURE_GLYPHS
    TextureGlyphData* tgData = param.Font->GetTextureGlyphData();
    if (tgData)
    {
        const TextureGlyph& tg = tgData->GetTextureGlyph(param.GlyphIndex);
        ImageInfoBase* image = tg.GetImageInfo(param.Font->GetBinding());
        if (image)
        {
            gv->Texture       = image->GetTexture(context.GetRenderer());
            gv->TextureWidth  = image->GetWidth();
            gv->TextureHeight = image->GetHeight();
        }
    }
    else
#endif
    {
        gv->Glyph = Cache.GetGlyph(context.GetRenderer(), 
                                   param, 
                                   shape, 
                                   gv->FontSize, 
                                   context.Log);
        if (gv->Glyph)
        {
            gv->>Texture = Cache.GetGlyphTexture(gv->Glyph);
            Cache.LockGlyph(gv->Glyph);
        }
    }

УЖОС!!!
Ты это, лучше такие аргументы не приводи, а то оторванную скобку нафиг запретят все

Я бы, например, намного лучше понял такой код:

    gv->DefaultInitWithGlyphParam( param );
#ifdef GFC_USE_TEXTURE_GLYPHS
    if( gv->Texture == 0 ) {
        tryInitTextureByGluphData( gv, context );
    }
#endif
    if( gv->Texture == 0 ) {
       tryInitByCache( gv, context );
    }
    assert( gv->Texture != 0 );

А ещё лучше и без условной компиляции по возможности как-то

Скажем так:

    gv->DefaultInitWithGlyphParam( param );
    if( gv->Texture == 0 ) {
        ON_GFC_USE_TEXTURE_GLYPHS_ONLY( tryInitTextureByGluphData( gv, context ) );
    }
    if( gv->Texture == 0 ) {
       tryInitByCache( gv, context );
    }
    assert( gv->Texture != 0 );

или совсем без препроцессора, а с глобальными константами...

    gv->DefaultInitWithGlyphParam( param );
    if( gv->Texture == 0 && g_UseTextureGlyphsOnly ) {
        tryInitTextureByGluphData( gv, context );
    }
    if( gv->Texture == 0 ) {
       tryInitByCache( gv, context );
    }
    assert( gv->Texture != 0 );

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

E>>>Можешь попробовать привести пример кода, где "перерасстановка скобок" существенно меняет его понятность

RO>>1.
RO>>

RO>>if(someQuiteLongCondition0 ||
RO>>    someQuiteLongCondition1) {
RO>>    doSomething();
RO>>}
RO>>

Так конечно же нехорошо, но попробуй писать так:

if(someQuiteLongCondition0 ||
        someQuiteLongCondition1) {
    doSomething();
}

И бить динные строки на короткие...

RO>>2.
RO>>

RO>>                doSomething();
RO>>                doSomething();
RO>>                doSomething();
RO>>            }
RO>>

RO>>Это что за блок заканчивается? Двигаем курсор на скобку, жмем клавишу «найти парную скобку». Видим:
RO>>

RO>>iteLongCondition0 ||
RO>>uiteLongCondition1) {
RO>>

RO>>И?

Попробуй форматировать программу так, чтобы она помещалась в обычный экран по ширине... Скажем 70 символов хорошее ограничение длины строки сверху...

KP>Отлично. У тебя получилось лучше аргументировать чем у меня.
KP>ну невозможно же читать такое!
Согласен, что невозможно, но в первую очередь из-за того, что строчки длинные.

KP>

KP>  if (someQuiteLongCondition0 ||
KP>      someQuiteLongCondition1 ||
KP>      someQuiteLongCondition2) {
KP>      doSomething1();
KP>      doSomething2();
KP>      doSomething3();
KP>  }
KP>

KP>ну невозможно же читать такое!

Очень похоже на стиль используемый в Microsoft.
Там только добавляют одну пустую строчу после {

  if ( someQuiteLongCondition0 ||
       someQuiteLongCondition1 ||
       someQuiteLongCondition2 ) {

      doSomething1();
      doSomething2();
      doSomething3();
  }

P.S.
Я предпочитаю писать логические операторы в начале строчки

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

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

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

KP>так я прям сопротивляюсь всеми фибрами души.
Я тоже когда-то сопротивлялся. А теперь даже так нравится, привык к этому стилю за месяц где-то, вначале было тяжело.
Что нравится — меньше строчек получается (имхо оптимально именно так, заодно можно выработать правило всегда оборачивать все, что после if в фигурные скобочки), а читаемость при определенной тренировке не падает совсем. Ну и некоторые вумные научные обоснования где-то были, типа если закомментируешь if случайно — то будет ошибка компиляции

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

E>Да уж, мегарежим
E>А с else ты что делаешь?

Нету там никакого else.

E>Я тебе советую так делать, кстати:
E>[c]static bool debugFlag = false;
E>if( debugFlag || ... )
E>{
E> int i = action();
E> . . .

Это полное ламерство. Спасибо, не катит.
Иногда попадаются такие "стили", сделаные "мега-профессионалами", полностью замусоренные всякими отладочными флагами, логами и совершенно бессмысленными коментариям на каждой строке (i++; // Increment i). Чтобы понять, что там происходит, приходится тратить время и тщательно чистить все это от грязи и ржавчины — чтобы просто увидеть, что же там происходит.

E>Ты это, лучше такие аргументы не приводи, а то оторванную скобку нафиг запретят все

E>Я бы, например, намного лучше понял такой код:

Спасибо, не катит.

Мы с тобой разговариваем на разных языках и занимаемся разными задачами. Это во-первых. Во-вторых, я ничего не понял из твоих примеров — твоя функциональная декомпозиция ужасна. Какой кайф в том, чтобы все запутать и замусорить, вместо того, чтобы поставить один-единственный и очевидный ifdef? Какой кайф в том, чтобы дублировать логику? Какой кайф в лишних ненужных операциях? Это риторические вопросы, можно не отвечать.

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

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

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

MS>Очень похоже на стиль используемый в Microsoft.
MS>Там только добавляют одну пустую строчу после {

Вот! Так же нередко поступают и в Java. Но если всё равно остается пустая строка, что мешает разместить «{» на ней?!

MS>Я предпочитаю писать логические операторы в начале строчки

А я так и не определился. У написания их в конце есть то преимущество, что сразу видно, что строка не завершена (слева это и так ясно):

if(f(x, y) == g(x, y) // это чья скобка?
    && someOtherCondition)
{
}

if(f(x, y) == g(x, y) && // ага, см. следующую строку
    someOtherCondition)
{
}

Зато иногда удобно писать так:

if(false
    || someCondition0
    || someCondition1
    || someCondition2
    || someCondition3
)
{
}

При таком расположении легко добавлять и удалять условия. В этом случае можно было бы разместить «)» и «{» на одной строке, но я их разделяю для единообразия.

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

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

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

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

KP>>так я прям сопротивляюсь всеми фибрами души.
E>Я тоже когда-то сопротивлялся. А теперь даже так нравится, привык к этому стилю за месяц где-то, вначале было тяжело.
E>Что нравится — меньше строчек получается (имхо оптимально именно так, заодно можно выработать правило всегда оборачивать все, что после if в фигурные скобочки),

а смысл экономить строчки?

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

.

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

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

MS>Нету там никакого else.
А если есть, то ты как действуешь в "отладочном режме"?

E>>Я тебе советую так делать, кстати:
E>>[c]static bool debugFlag = false;
E>>if( debugFlag || ... )
E>>{
E>> int i = action();
E>> . . .

MS>Это полное ламерство. Спасибо, не катит.
MS>Иногда попадаются такие "стили", сделаные "мега-профессионалами", полностью замусоренные всякими отладочными флагами, логами и совершенно бессмысленными коментариям на каждой строке (i++; // Increment i).
За признание моего мегапрофессионализма спасибо конечно, но таки ты не понял моего совета.
Я тебе советовал делать так на время, когда ты комментишь
Просто при таком способе, даже если ты забудешь убрать коммент, то ничего плохого не случится.

Про то, что отлаживаться лучше вообще совсем иначе, я и не говорю

MS>Мы с тобой разговариваем на разных языках и занимаемся разными задачами. Это во-первых. Во-вторых, я ничего не понял из твоих примеров — твоя функциональная декомпозиция ужасна. Какой кайф в том, чтобы все запутать и замусорить, вместо того, чтобы поставить один-единственный и очевидный ifdef? Какой кайф в том, чтобы дублировать логику? Какой кайф в лишних ненужных операциях? Это риторические вопросы, можно не отвечать.

Почему ужасна? Почему "инициализация текстуры таким-то образом" или "инициализация текстуры другим образом" это плохая декомпозиция?
Но в любом случае я же не знаю что обозначают все твои структуры. Я бы совсем иначе делал

MS>Опытный инженер отличается от юниора в том числе и тем, что он более-менее оптимально разделяет функциональность. Не укрупняет, но и не дробит в мелкую крошку. Он делает опмимально. В то время, как юниора все время заносит либо в ту, либо в другую сторону. В моем примере решение близко к оптимальному.

Самокритично так

Лично мне, например, очень неудобно читать что будет в случае если такая условная компиляция или другая.
Ну мне, например, не нравится, что в одном случае объявляется переменная tgData, которая видна после if'а, а в другом нет...
Ну и вообще мне не понятно из стовего кода, например, должно в конце поле gv->Texture обязательно инициализироваться чем-то ненулевым или нет, и если таки должна, то в каком случае чем (как при использовании так и не при использовании макроса)

MS>Я это пишу не для тебя. Я пишу это, чтобы новички не приняли твои слова за чистую монету. В твоем случае, есть сильное подозрение, что пациент принципиально не обучаем (в народе говорят "как об стенку горох").
Ещё раз спасибо. Признаюсь, что такими аргументами меня обучить действительно затруднительно

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

KP>я себе слабо представляю как можно *случайно* что-то закомментировать

Так, например

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

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

KP>>я себе слабо представляю как можно *случайно* что-то закомментировать

E>Так, например

Так там как раз закомментировали не случайно

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

E>>Так, например

KP>Так там как раз закомментировали не случайно
Упс, я имел в виду описаный в ответе сценарий "закомментировалии забыли"

MS>Не говоря уже об условной компиляции. Вот пример из реального проекта:
MS>

    gv->>GlyphParam    = param;
    gv->>Glyph         = 0;
    gv->>Texture       = 0;
    gv->>TextureWidth  = 0;
    gv->>TextureHeight = 0;
MS>#ifdef GFC_USE_TEXTURE_GLYPHS
MS>    TextureGlyphData* tgData = param.Font->GetTextureGlyphData();
MS>    if (tgData)
MS>    {
MS>        const TextureGlyph& tg = tgData->GetTextureGlyph(param.GlyphIndex);
MS>        ImageInfoBase* image = tg.GetImageInfo(param.Font->GetBinding());
MS>        if (image)
MS>        {
            gv->>Texture       = image->GetTexture(context.GetRenderer());
            gv->>TextureWidth  = image->GetWidth();
            gv->>TextureHeight = image->GetHeight();
MS>        }
MS>    }
MS>    else
MS>#endif
MS>    {
        gv->>Glyph = Cache.GetGlyph(context.GetRenderer(), 
MS>                                   param, 
MS>                                   shape, 
                                   gv->>FontSize, 
MS>                                   context.Log);
MS>        if (gv->Glyph)
MS>        {
            gv->>Texture = Cache.GetGlyphTexture(gv->Glyph);
MS>            Cache.LockGlyph(gv->Glyph);
MS>        }
MS>    }
MS>

В Microsoft как всегда не ищут лёгких путей.
Т.е. пожертвовали компактностью, но стиль кода не сменили даже ради одного случая.
(написали два #if/#endif но стиль сохранили)
Когда я пишу в таком стиле, то в подобных случаях им жертвую.

#if defined(_WIN64)
    if (IoIs32bitProcess( Irp )) {

        if (IrpSp->Parameters.FileSystemControl.InputBufferLength != sizeof(UINT32)) {
            
            FatCompleteRequest( FatNull, Irp, STATUS_INVALID_PARAMETER );

            DebugTrace(-1, Dbg, "FatInvalidateVolumes -> %08lx\n", STATUS_INVALID_PARAMETER);
            return STATUS_INVALID_PARAMETER;
        }

        Handle = (HANDLE) LongToHandle( (*(PUINT32)Irp->AssociatedIrp.SystemBuffer) );
    } else {
#endif
        if (IrpSp->Parameters.FileSystemControl.InputBufferLength != sizeof(HANDLE)) {

            FatCompleteRequest( FatNull, Irp, STATUS_INVALID_PARAMETER );

            DebugTrace(-1, Dbg, "FatInvalidateVolumes -> %08lx\n", STATUS_INVALID_PARAMETER);
            return STATUS_INVALID_PARAMETER;
        }

        Handle = *(PHANDLE)Irp->AssociatedIrp.SystemBuffer;
#if defined(_WIN64)
    }
#endif

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

MS>>Нету там никакого else.
E>А если есть, то ты как действуешь в "отладочном режме"?

Блочными коментариями. Неужели не очевидно?

E>За признание моего мегапрофессионализма спасибо конечно, но таки ты не понял моего совета.
E>Я тебе советовал делать так на время, когда ты комментишь
E>Просто при таком способе, даже если ты забудешь убрать коммент, то ничего плохого не случится.

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

E>Про то, что отлаживаться лучше вообще совсем иначе, я и не говорю

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

E>Почему ужасна? Почему "инициализация текстуры таким-то образом" или "инициализация текстуры другим образом" это плохая декомпозиция?
E>Но в любом случае я же не знаю что обозначают все твои структуры. Я бы совсем иначе делал

Потому ужасна, что все порубано в слишком мелкую крошку. Многие не понимают, что это тоже плохо. Вместо того, чтобы охватить логику одним взглядом, приходится скакать туда-сюда, чтобы понять, а что же происходит. А просходит какая-нибудь мелочь. Грамотная декомпозиция функциональности — это гигантская проблема современных программистов. Электронщики в этом плане гораздо опытнее и мудрее. Наверное потому, что ошибки декомпозиции обходятся им гораздо дороже.

E>Ну и вообще мне не понятно из стовего кода, например, должно в конце поле gv->Texture обязательно инициализироваться чем-то ненулевым или нет, и если таки должна, то в каком случае чем (как при использовании так и не при использовании макроса)

Если нет ассерта, значит не обязательно. По-моему так. Был у меня прецедент — некие умники понаставили в моем алгоритме ассетов, потому что им показалось что так будет првильнее. И главное — именно в тех местах, где нуль-поинтеры были совершенно нормальной штатной ситуацией. А потом начали жаловаться, что вываливается по ассерту. Когда я понял в чем дело, то слегка офигел.

А условная компиляция нужна именно потому, что если не определена эта макро-константа, то в природе просто не существует ни TextureGlyph, ни ImageInfoBase, ни Font::GetBinding(). А если определена, то это тащит за собой еще тонну кода, что на всяких Sony PSP может быть очень критичным. Да и даже не в этом дело, а например, в соблюдении законов об интеллектуальной собственности. И зачем, ну зачем еще дробить такую тривиальную логику в еще более мелкую крошку?

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

E>Так конечно же нехорошо, но попробуй писать так:
E>

E>if(someQuiteLongCondition0 ||
E>        someQuiteLongCondition1) {
E>    doSomething();
E>}
E>

Так красивше

if(someQuiteLongCondition0 ||
       someQuiteLongCondition1 ||
            someQuiteLongCondition2 ||
                someQuiteLongCondition3) {
    doSomething();
}

E>И бить динные строки на короткие...

А вот это правильно. Я привык к мониторам, на которых умещается три колонки исходников. Не более 80 символов каждая. И минимум 60 строк в высоту. Хотя и из этого бывают исключения, но редко. Здесь главное — без фанатизма.

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

MS>Блочными коментариями. Неужели не очевидно?
Ну мало ли что у крутых программеров принято

Может ты

if( true ) {}

вписываешь

А что мешает действоватьодинаково в случае когда else есть и когда нет?

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

Очень даже может быть. Алгоритмы, они разные бывают... Я вот, например, пишу макеты и тестовые драйверы, которые потом остаются для развитияи и поддержки...
Но вот "не забуду" -- это не убеждает. Я слишком много чужого такого "незабываемого" кода за жизнь вычистил из прог

E>>Про то, что отлаживаться лучше вообще совсем иначе, я и не говорю

MS>Ну это только твое мнение. Отладка бывает разная, в том числе бывают случаи, когда ни точки останова, ни пошаговое выполнение не помогают в принципе.
А точки останова и пошаговое выполнение -- это ещё хуже, ИМХО

MS>Грамотная декомпозиция функциональности — это гигантская проблема современных программистов.
А ты можешь пояснить почему крошка "слишком мелкая"? Казалось бы у тебя там сначала записан "конструктор" структуры от параметров, но в нулевом состоянии,
Потом она доинициализируется разными способами. Я бы всё это методами сделали звал их.
Тогда уровень "какие способы инициализации и доинициализации зовём" был бы в одном местеописан, а конкретные действия в описанных рядом методах... Обычно тебе либо тот уровень нужен, либо другой, вроде...

MS>Если нет ассерта, значит не обязательно. По-моему так.
Так как у тебя там нет ни одного assert, то это, ИМХО, не очевидно

Мало того, мог бы коммент написать что ли...

MS>Был у меня прецедент — некие умники понаставили в моем алгоритме ассетов, потому что им показалось что так будет првильнее. И главное — именно в тех местах, где нуль-поинтеры были совершенно нормальной штатной ситуацией. А потом начали жаловаться, что вываливается по ассерту. Когда я понял в чем дело, то слегка офигел.

Ну и я про то же. Такой код, как ты привёл, трудно поддерживать, особенное если он чужой
Ты мне всё ещё не веришь?

MS>А условная компиляция нужна именно потому, что если не определена эта макро-константа, то в природе просто не существует ни TextureGlyph, ни ImageInfoBase, ни Font::GetBinding(). А если определена, то это тащит за собой еще тонну кода, что на всяких Sony PSP может быть очень критичным. Да и даже не в этом дело, а например, в соблюдении законов об интеллектуальной собственности. И зачем, ну зачем еще дробить такую тривиальную логику в еще более мелкую крошку?

Ну, например, чтобы те, кто на Sony PSP не заморачивались...

Я бы сделал какой-то слой-нелпер, который от запчастей лишних на Sony PSP изолирует, если надо, а весь код условной компиляцией не перепахивал бы

Ну да у всех свои приоритеты.
У меня они такие: надёжность и поддерживаемость другими людьми

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

MS>Так красивше

MS>

MS>if(someQuiteLongCondition0 ||
MS>       someQuiteLongCondition1 ||
MS>            someQuiteLongCondition2 ||
MS>                someQuiteLongCondition3) {
MS>    doSomething();
MS>}
MS>

Лично мне больше нравится так:

if(someQuiteLongCondition0 
       || someQuiteLongCondition1
       || someQuiteLongCondition2
       || someQuiteLongCondition3) {
    doSomething();
}

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

E>Ну и я про то же. Такой код, как ты привёл, трудно поддерживать, особенное если он чужой
E>Ты мне всё ещё не веришь?

Не верю. Мой код легко поддерживать и модифицировать. Тому есть многочисленные подтвержения на мировом уровне.

E>Я бы сделал какой-то слой-нелпер, который от запчастей лишних на Sony PSP изолирует, если надо, а весь код условной компиляцией не перепахивал бы

Дык это и есть тот самый слой-хелпер.

E>Ну да у всех свои приоритеты.
E>У меня они такие: надёжность и поддерживаемость другими людьми

Именно так. Но у нас с тобой разные критерии о "надежности и поддерживаемости". Я опираюсь на опыт и отклики большого количества других людей, а ты похоже исходишь из своих субъективных критериев.

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

E>Так конечно же нехорошо, но попробуй писать так:
E>

E>if(someQuiteLongCondition0 ||
E>        someQuiteLongCondition1) {
E>    doSomething();
E>}
E>

Коряво выглядит

E>И бить динные строки на короткие...
У него и так они разбиты на короткие

E>Попробуй форматировать программу так, чтобы она помещалась в обычный экран по ширине... Скажем 70 символов хорошее ограничение длины строки сверху...
Строка то как раз не длиннее 70 символов.

E>Согласен, что невозможно, но в первую очередь из-за того, что строчки длинные.

Где они тут длинные?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

RO>if(someQuiteLongCondition0 ||
RO>    someQuiteLongCondition1) {
RO>    doSomething();
RO>}

RO>if(someQuiteLongCondition0 ||
RO>    someQuiteLongCondition1)
RO>{
RO>    doSomething();
RO>}

Мой вариант:

if(
    someQuiteLongCondition0 ||
    someQuiteLongCondition1
) {
    doSomething();
}

Впрочем и вызов функции не помещающийся на одной строке записываю подобным образом:

someFunction(
    someQuiteLongArgument0,
    someQuiteLongArgument1,
    someQuiteLongArgument2,
    someQuiteLongArgument3,
    someQuiteLongArgument4,
    someQuiteLongArgument5
);

А не так:

someFunction(someQuiteLongArgument0,
    someQuiteLongArgument1,
    someQuiteLongArgument2,
    someQuiteLongArgument3,
    someQuiteLongArgument4,
    someQuiteLongArgument5);

То есть подобно фигурным скобкам. Вряд ли кто пишет что-нибудь вроде:

    if (someCondition) { someQuiteLongExpression0;
        someQuiteLongExpression1;
        someQuiteLongExpression2; }

Я даже не видел такого:

    if (someCondition) {
        someQuiteLongExpression0;
        someQuiteLongExpression1;
        someQuiteLongExpression2; }

Хотя против последнего не возражаю.

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

CC>Где они тут длинные?

Ну там было написано someQuiteLongCondition0

Если скобку видно, то уже лучше намного становится

Но с двойным отступом ещё лучше таки читается.

ИМХО оба стиля вполне терпимые. И нет никакой необходимости навязывать выбор одного из них, хотя если его навязать то тоже ничего особо страшного нет, кроме библиотечного и старого кода.

Мне не понять от чего людям трудно перестроться

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

E>>Я бы сделал какой-то слой-нелпер, который от запчастей лишних на Sony PSP изолирует, если надо, а весь код условной компиляцией не перепахивал бы

MS>Дык это и есть тот самый слой-хелпер.

Дык надо было про это и рассказать. Я так понял, что это типичный код из проекта

Но в нём всё равно маловато, на мой вкус, комментариев и assert'ов.

И главное, я так и не понял почему тебе кажется, что такое причудливое переплетение оперетора if и дерективы #ifdef легко понимается, читается и поддерживается?

Мне собственно не понравилось именно это. Если тебе удобнее не дробить на функции, то можно не дробить, а подставить их обратно. На структуру кода это, ИМХО, никак не повлияет.

Опять же вопрос, а что ты пишешь, если там надо два разных #ifdef приделать?
Ну типа будет у текстуры не два варианта инициализации, а три, при этом они все пробуются по очереди, но на некоторых платформах каких-то из них нет.

Почему для случая "две альтернативы" и для случая "три альтернативы" надо применать разные техники использования условной компиляции?

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

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

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

Меня давно заставили. Особо не напрягает, но если пишу для себя, то только

if(...)
{
}

korzh.pavel пишет:

> И вообще, я могу жить с любой нотацией, мне воротит только от трёх
> вещей, когда пишешь на C++:
> 1. Венгерская нотация
> 2. Имена классов начинающееся с 'C'
> 3. Когда фигурную скобку ставят на одной строке с условием.

+1.

Posted via RSDN NNTP Server 2.1 beta

Roman Odaisky пишет:
> if(someQuiteLongCondition0 ||
> someQuiteLongCondition1) {
> doSomething();
> }

Что интересно, наши при этом делают одну
пустую строку после открывающейся фигурной скобки,
чтобы тело отделирь от условия.

if(someQuiteLongCondition0 ||
someQuiteLongCondition1) {

doSomething();
}

Т.е. ИМ ВСЕ РАВНО НЕ УДОБНО, но они низачто не сменят
свой стиль.

Posted via RSDN NNTP Server 2.1 beta

MShura пишет:

> Очень похоже на стиль используемый в Microsoft.
> Там только добавляют одну пустую строчу после {

Ужос ! Значит мне в микрасофт дорога заказана.

Posted via RSDN NNTP Server 2.1 beta

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

MS>А вот это правильно. Я привык к мониторам, на которых умещается три колонки исходников. Не более 80 символов каждая. И минимум 60 строк в высоту. Хотя и из этого бывают исключения, но редко. Здесь главное — без фанатизма.

Прошу прощения за офтоп. Можешь рассказать, каким ИДЕ пользуешься?

I>Мой вариант:

I>

I>if(
I>    someQuiteLongCondition0 ||
I>    someQuiteLongCondition1
I>) {
I>    doSomething();
I>}
I>

А я вот так поступаю. Читабельнось, имхо, повышается:

if
(
    someQuiteLongCondition0 ||
    someQuiteLongCondition1
)
{
    doSomething();
}

И в функциях также:

class:class
(
    int param_1,
    int param_2,
    ...
    int param_N
):
    m_param_1 (param_1),
    m_param_2 (param_2),
    ...
    m_param_N (param_N)
{
    DoSomething ();
    ...
} // class:class

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

I>Мой вариант:

I>

I>if(
I>    someQuiteLongCondition0 ||
I>    someQuiteLongCondition1
I>) {
I>    doSomething();
I>}
I>

I>Впрочем и вызов функции не помещающийся на одной строке записываю подобным образом:

I>

I>someFunction(
I>    someQuiteLongArgument0,
I>    someQuiteLongArgument1,
I>    someQuiteLongArgument2,
I>    someQuiteLongArgument3,
I>    someQuiteLongArgument4,
I>    someQuiteLongArgument5
I>);
I>

Хороший вариант. Я располагаю скобки на отдельных строках, если строк больше двух. Хотя разве это так уж важно?

I>А не так:

I>

I>someFunction(someQuiteLongArgument0,
I>    someQuiteLongArgument5);
I>

Вот если строк всего две, то, по-моему, дальше разбивать излишне.

I>Я даже не видел такого:

I>

I>    if (someCondition) {
I>        someQuiteLongExpression0;
I>        someQuiteLongExpression1;
I>        someQuiteLongExpression2; }
I>

I>Хотя против последнего не возражаю.

А я возражаю! Еще есть любители писать так:

  void f()
{ hello();
  if(1)
  { world();
    somethingElse();
  }
}

Нельзя располагать скобку на той же строке. Это мешает ее переместить на другое место, удалить, вставить.

MS>Это было оправдано во времена алфавитных дисплеев, когда на экране умещалось очень мало текста.
Ладно писать, а вот когда читать ЭТО приходится

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

KP>Здравствуйте, c-smile, Вы писали:

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

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

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

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

CS>>Это ж кто у нас там такой любитель?

KP>

KP>PKv

Я пишу со скобкой на той же строке и не расставляю пробельчики между операторами и круглыми скобками,
некоторые пишут тоже без пробельчиков но скобки с новой строки, а некоторые делают и то и другое.
Все норм, все уживаемся, никто не жалуется на читабельность.
Более того, это сразу помогает идентифицировать автора если что не так

Правда С перед именами не ставит никто, но если бы кто-то и ставил, от ужаса бы никто не помер

Переменные также в вольном стиле. lpctstrString и подобные извращения никто не использует, но префикс из 1 буквы ставится частенько.
Кто ставит 'p' перед указателем, кто любит 'a' ставить, иногда 'с', короче кому как нравится.

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

E>И главное, я так и не понял почему тебе кажется, что такое причудливое переплетение оперетора if и дерективы #ifdef легко понимается, читается и поддерживается?

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

E>Мне собственно не понравилось именно это. Если тебе удобнее не дробить на функции, то можно не дробить, а подставить их обратно. На структуру кода это, ИМХО, никак не повлияет.

E>Опять же вопрос, а что ты пишешь, если там надо два разных #ifdef приделать?
E>Ну типа будет у текстуры не два варианта инициализации, а три, при этом они все пробуются по очереди, но на некоторых платформах каких-то из них нет.

E>Почему для случая "две альтернативы" и для случая "три альтернативы" надо применать разные техники использования условной компиляции?

Трех альтернатив в данном случае нету. И не будет никогда. Это определено сущностью задачи, и, если угодно, математической сущностью законов этого мира. Так зачем все переусложнять?

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

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

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

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

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

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

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

KP>И вообще, я могу жить с любой нотацией, мне воротит только от трёх вещей, когда пишешь на C++:

KP>1. Венгерская нотация

KP>2. Имена классов начинающееся с 'C'

KP>3. Когда фигурную скобку ставят на одной строке с условием.

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

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

_>А меня вообще ни от чего не воротит, у нас все пишут как привыкли и никто никого не заставляет

Ужас. Как же вы договариваетесь о более серьезных вещах?

_>Я пишу со скобкой на той же строке и не расставляю пробельчики между операторами и круглыми скобками,
_>некоторые пишут тоже без пробельчиков но скобки с новой строки, а некоторые делают и то и другое.
_>Все норм, все уживаемся, никто не жалуется на читабельность.

По-прежнему ужас.

_>Более того, это сразу помогает идентифицировать автора если что не так

"cvs ann" и "svn blame" у вас не в почете, видимо? Снова ужас.

_>Правда С перед именами не ставит никто, но если бы кто-то и ставил, от ужаса бы никто не помер

_>Переменные также в вольном стиле. lpctstrString и подобные извращения никто не использует, но префикс из 1 буквы ставится частенько.
_>Кто ставит 'p' перед указателем, кто любит 'a' ставить, иногда 'с', короче кому как нравится.

Мне это не нравится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KP>>И вообще, я могу жить с любой нотацией, мне воротит только от трёх вещей, когда пишешь на C++:

KP>>1. Венгерская нотация

KP>>2. Имена классов начинающееся с 'C'

KP>>3. Когда фигурную скобку ставят на одной строке с условием.

AA>Все-таки у тебя, видимо, очень много свободного времени, если его остается на беспокойство о таких мелочах. Об этом надо договориться один раз и использовать. Спорить, где скобка лучше — бред полный.

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

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

if (flag) {
  //...
}

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

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

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

MS>Трех альтернатив в данном случае нету. И не будет никогда. Это определено сущностью задачи, и, если угодно, математической сущностью законов этого мира. Так зачем все переусложнять?

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

Здравствуйте, 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 тоже не бывает, не говоря уже о "трех вариантах". На что ты тут начал мощно вопить про "ужас ужас". А проблема-то не стоит и яичной скорлупы. Короче говоря, тебя не должен беспокоить пустяковый вопрос сопровождения и поддержки приведенного решения.

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

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

	От:	MasterZiv
	Дата:	18.09.07 07:30
	Оценка:	1 (1) -1

	От:	korzh.pavel
	Дата:	18.09.07 08:56
	Оценка:

	От:	s_viy
	Дата:	18.09.07 08:59
	Оценка:

От:	ДимДимыч	http://klug.org.ua
Дата:	18.09.07 09:09
Оценка:

	От:	MShura
	Дата:	18.09.07 09:55
	Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	18.09.07 12:02
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	18.09.07 13:53
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	18.09.07 21:55
Оценка:

	От:	Roman Odaisky
	Дата:	19.09.07 12:51
	Оценка:	14 (1)

	От:	Alex Alexandrov
	Дата:	25.09.07 19:07
	Оценка:

	От:	Пётр Седов
	Дата:	26.09.07 13:21
	Оценка: