if (_CreateDir(sFile))
    if (CopyFile(lpszTemp, sFile, FALSE))
        _tcsicmp(m_lpszFile, sFile);

_CreateDir(sFile) &&
CopyFile(lpszTemp, sFile, FALSE) &&
(_tcsicmp(m_lpszFile, sFile), 1); // и т.д. из &&

 open HANDLE, "filename"
        or die "Can't open: $!\n";

foo() :-
    bar(),
    baz(),
    buz().
foo() :-
    bur(),
    buz().

bool foo() {
    return 
        ( bar() && baz() && buz() ) ||
        ( bur() && buz() );
}

50. Не путайте привычность с читаемостью
(Или синдром "настоящего программиста, который может программировать на любом языке как на ФОРТРАНе").

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

#define begin {
#define end }
while ( ... )
begin
// ...
end

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

Родственная проблема связана с использованием макросов препроцессора для скрытия синтаксиса объявлений Си. Например, не делайте следующего:

typedef const char *LPCSTR;
LPCSTR str;

Подобные вещи вызывают проблемы с сопровождением, потому что кто-то, не знакомый с вашими соглашениями, будет должен просматривать typedef, чтобы разобраться, что происходит на самом деле.
Дополнительная путаница возникает в Си++, потому что читатель может интерпретировать происходящее, как определение объекта Си++ из класса LPCSTR. Большинству программистов на Си++ не придет в голову, что LPCSTR является указателем. Объявления Си очень легко читаются программистами на Си. (Кстати, не путайте вышеупомянутое с разумной практикой определения типа word в виде 16-битового числа со знаком для преодоления проблемы переносимости, присущей типу int, размер которого не определен ни в ANSI Си, ни в ANSI Си++).
К тому же, многие программисты избегают условной операции ?: просто потому, что она им кажется непонятной. Тем не менее, это условное выражение может существенно упростить ваш код и, следственно, сделать его лучше читаемым. Я думаю, что:

printf("%s", str ? str : "<пусто>");

гораздо элегантнее, чем:

if ( str == NULL )
  printf( "<пусто>" );
else
  printf( "%s", str );

Вы к тому же экономите на двух вызовах printf(). Мне также часто приходится видеть неправильное использование операций ++ и --. Весь смысл автоинкремента или автодекремента заключается в соединении этих операций с другими. Вместо:

while ( *p )
{
  putchar ( *p );
  ++p;
}

или:

for( ; *p ; ++p )
  putchar ( *p );
используйте:
while( *p )
  putchar ( *p++ );

Этот код вполне читаем для компетентного программиста на языке Си, даже если ему нет эквивалентной операции в ФОРТРАНе или Паскале.
Вы также никогда не должны прятать операторы в макросах из-за того, что вам просто не нравится, как они выглядят. Я однажды видел следующее в реальной программе:

struct tree_node
{
  struct tree_node *lftchld;
};
#define left_child(x) ((x)->lftchld)
//...
traverse( tree_node *root )
{
  if( left_child(root) )
    traverse( left_child( root ) );
// ...
}

Программист намеренно сделал определение структуры труднее читаемым для того, чтобы избежать конфликта имен между полем и совершенно необходимым макросом, и все из-за того, что ему не нравился внешний вид оператора ->. Для него было бы гораздо лучшим
Правила обычного программирования выходом просто назвать поле left_child и совсем избавиться от макроса.
Если вы действительно думаете, что программа должна внешне выглядеть как на Паскале, чтобы быть читаемой, то вы должны программировать на Паскале, а не на Си или Си++.

_CreateDir(sFile)
  && (CopyFile(lpszTemp, sFile, FALSE))
  && _tcsicmp(m_lpszFile, sFile)
  ;

ГА>bool foo() {
ГА>    return 
ГА>        ( bar() && baz() && buz() ) ||
ГА>        ( bur() && buz() );
ГА>}

int __forceinline bp() { __asm int 3 }

bool foo() {
    return 
        ( bar() && 
    bp(),
        baz() && buz() ) ||
        ( bur() && buz() );
}

BOOL result =
    _CreateDir(sFile) &&
    CopyFile(lpszTemp, sFile, FALSE) &&
    _tcsicmp(m_lpszFile, sFile) > 1;

GN>>>>_CreateDir(sFile)
GN>>>>  && (CopyFile(lpszTemp, sFile, FALSE))
GN>>>>  && _tcsicmp(m_lpszFile, sFile)
GN>>>>  ;

int __forceinline bp() { __asm int 3 }

bp();
_CreateDir(sFile)
  && (CopyFile(lpszTemp, sFile, FALSE))
  && _tcsicmp(m_lpszFile, sFile)
  ;

int __forceinline bp() { __asm int 3 }

_CreateDir(sFile)
  && 
bp(),
    (CopyFile(lpszTemp, sFile, FALSE))
  && _tcsicmp(m_lpszFile, sFile)
  ;

//before
void foo_ugly() {
  if ( condition1 ) {
        if ( condition2 ) {
            if ( condition3 ) {
                do_actual_work();
            } else {
                cout << "Too bad, condition3 was false";
            }
        }    else {
            cout << "Too bad, condition2 was false";
        }
    } else {
        cout << "Too bad, condition1 was false";
    }
}
//after
void foo_much_better() {
    if(!condition1) {
        cout << "Too bad, condition1 was false";
    } else if(!condition2) {
        cout << "Too bad, condition2 was false";
    } else if(!condition3) {
        cout << "Too bad, condition3 was false";
    } else {
        do_actual_work();
    }
}

bool_func1() && bool_func2() || (void_func1(), void_func2(), bool_func3());

ГА>    if ( condition3 ) {
ГА>        do_actual_work();
ГА>    }

if ( condition3 )
    {
    //
    }

if ( condition() )
    {
    // здесь может быть, а может и не быть несколько строк кода.
    if ( some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() ) {
        do_actual_work();
    }

GN>>if ( condition() )
GN>>    {
GN>>    // здесь может быть, а может и не быть несколько строк кода.
GN>>    if ( some_other_complex_condition_that_does_a_lot_of_calculations_and_goes_out_of_the_screen() ) {
GN>>        do_actual_work();
GN>>    }
GN>>

GN>>К чему относится нижняя скобка?

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

C>Стоит ли мопед свеч?

if (!_CreateDir(sFile)) {
    //    возможно обработка ситуации
    return false;
}
if (!CopyFile(lpszTemp, sFile, FALSE)) {
    //    опять возможна обработка ошибочной ситуации
    return false
}
    return _tcsicmp(m_lpszFile, sFile);

R>А много ли ты знаешь компиляторов которые на 100% соответствуют стандарту?

    assert( p!=0 && p->IsValid() );   //   Довольно общепринятая практика

C>>Выделенное курсивом — верно

R>А много ли ты знаешь компиляторов которые на 100% соответствуют стандарту?

if (ptr && ptr[0] == SOME_MAGIC_NUMBER)
{
    fprintf(stderr, "Bingo!");
}

E>>Ну я вообще ратую за короткие и простые функции с ясной семантикой

E>>Ну а для такого сложного действия, как обсуждается тут (там помнится речь шла о десятке if'ов ) совершенно точно стоит заводить отдельную функцию

You have a long method that uses local variables in such a way that you cannot apply Extract Method.

Turn the method into its own object so that all the local variables become fields on that object.
You can then decompose the method into other methods on the same object.

Mechanics
Stolen shamelessly from Beck [Beck].

• Create a new class, name it after the method.
  
• Give the new class a final field for the object that hosted the original method (the source object) and a field for each temporary variable and each parameter in the method.
  
• Give the new class a constructor that takes the source object and each parameter.
  
• Give the new class a method named “compute”.
  
• Copy the body of the original method into compute. Use the source object field for any invocations of methods on the original object.
  
• Compile.
  
• Replace the old method with one that creates the new object and calls compute.

Now comes the fun part. Because all the local variables are now fields, you can freely decompose the method without having to pass any parameters.