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

Здравствуйте, 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>>

От:	McSeem2	http://www.antigrain.com
Дата:	19.09.07 13:18
Оценка:	+2

	От:	korzh.pavel
	Дата:	19.09.07 13:21
	Оценка:

	От:	Erop
	Дата:	19.09.07 14:12
	Оценка:	4 (2) +1

	От:	Erop
	Дата:	19.09.07 14:17
	Оценка:

	От:	MShura
	Дата:	19.09.07 14:30
	Оценка:	+1

	От:	Roman Odaisky
	Дата:	19.09.07 15:13
	Оценка:	+1

	От:	CreatorCray
	Дата:	20.09.07 05:58
	Оценка: