Почему Вы использовали бы присвоение в условии?

Более полезно, если Вы вызываете функцию:

if (n = foo())
{
    /* foo returned a non-zero value, do something with the return value */
} else {
    /* foo returned zero, do something else */
}

Несомненно, можно просто поместить n = нечто (); на отдельном операторе тогда, если (n), но я думаю, вышеупомянутое является довольно читаемой идиомой.

Может быть полезно, если Вы вызываете функцию, которая возвращает или данные, чтобы продолжить работать или флаг для указания на ошибку (или что Вы сделаны).

Что-то как:

while ((c = getchar()) != EOF) {
    // process the character
}

// end of file reached...

Лично это - идиома, которую я чрезвычайно не люблю, но иногда альтернатива более ужасна.

GCC может помочь Вам обнаружить (с - Стена), если Вы неумышленно пытаетесь использовать присвоение в качестве значения истинности, в случае, если это рекомендует, чтобы Вы записали

if ((n = foo())) {
   ...
}

Т.е. использовали дополнительную круглую скобку, чтобы указать, что это действительно, что Вы хотите.

Идиома более полезна, когда Вы пишете while цикл вместо if оператор. Для if оператор, можно разбить его, как Вы описываете. Но без этой конструкции, необходимо было бы или повторить себя:

c = getchar();
while (c != EOF) {
    // ...
    c = getchar();
}

или использование loop-and-a-half структура:

while (true) {
    c = getchar();
    if (c == EOF) break;
    // ...
}

я обычно предпочитал бы форму loop-and-a-half.

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

В PHP, например, это полезно для цикличного выполнения через результаты базы данных SQL:

while ($row = mysql_fetch_assoc($result)) {
    // Display row
}

Это выглядит намного лучше, чем:

$row = mysql_fetch_assoc($result);
while ($row) {
    // Display row
    $row = mysql_fetch_assoc($result);
}

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

if ((rc = first_check(arg1, arg2)) != 0)
{
    report error based on rc
}
else if ((rc = second_check(arg2, arg3)) != 0)
{
    report error based on new rc
}
else if ((rc = third_check(arg3, arg4)) != 0)
{
    report error based on new rc
}
else
{
    do what you really wanted to do
}

, альтернатива (не использование присвоения в условии):

rc = first_check(arg1, arg2);
if (rc != 0)
{
    report error based on rc
}
else
{
    rc = second_check(arg2, arg3);
    if (rc != 0)
    {
        report error based on new rc
    }
    else
    {
        rc = third_check(arg3, arg4);
        if (rc != 0)
        {
            report error based on new rc
        }
        else
        {
            do what you really wanted to do
        }
    }
}

С длительной проверкой ошибок, альтернатива может убежать RHS страницы, тогда как версия присвоения в условном выражении не делает этого.

проверки на ошибки могли также быть 'действиями' — first_action(), second_action(), third_action() —, конечно, а не просто проверяют. Таким образом, они могли быть проверены шаги в процессе, которым справляется функция. (Чаще всего в коде я работаю с, функции вроде проверок предварительного условия или выделений памяти, необходимых для функции для работы, или вдоль подобных строк).

Я нахожу это очень полезным с функциями, возвращаясь optionals (boost::optional или std::optional в C++ 17):

std::optional<int> maybe_int(); // function maybe returns an int

if (auto i = maybe_int()) {
    use_int(*i);
}

Это уменьшает объем моей переменной, делает код более компактным и не препятствует удобочитаемости (я нахожу).

То же с указателями:

int* ptr_int();

if (int* i = ptr_int()) {
    use_int(*i);
}