История изменений
Исправление firkax, (текущая версия) :
Если брать только этот кусок сферически в вакууме, то читаемость и правда не сильно изменилась - он и так и так максимально простой. Но когда такого кода тысячи и десятки тысяч строк, это утомляет. Собственно, конкретно программа автора может быть оформлена как угодно, хоть без форматирования вообще - она и так и так простая, но лучше сразу привыкать к хорошему оформлению.
А ещё в первом присваивание можно засунуть внутрь if():
static void bleh(void)
{
struct foobar *f;
struct bar *b;
int i, ret;
if (!(f = foobar_new()))
errx(1, "cannot create f");
if (!(b = bar_new()))
errx(1, "cannot create b");
for (i = 0; i < b->nr_somethings; ++i)
if (ret = f->ops->do(&b->somethings[i]))
errx(1, "cannot do something: %d", ret);
foobar_free(f);
bar_free(b);
}
В C23 появился auto и теперь все ваще хорошо:
Я бы не сказал. Теперь, чтобы узнать, какого типа переменные f и b, придётся искать прототипы нужных функций, которые в общем случае (если человек видит этот код в первый раз, например) неизвестно где. Хотя конкретно у тебя эти функции выглядят как конструкторы динамических структур и тип скорее всего можно угадать, но в общем случае это не так. А ещё может так случиться, что тип возврата какой-то функции поменяют вместе с семантикой её использования вообще, рассчитывая на то, что в местах, где он используется, код сломается, компилятор выдаст ошибку и всё можно будет поправить, но из-за auto этого не случится и в коде появится баг.
Исправление firkax, :
Если брать только этот кусок сферически в вакууме, то читаемость и правда не сильно изменилась - он и так и так максимально простой. Но когда такого кода тысячи и десятки тысяч строк, это утомляет. Собственно, конкретно программа автора может быть оформлена как угодно, хоть без форматирования вообще - она и так и так простая, но лучше сразу привыкать к хорошему оформлению.
А ещё в первом присваивание можно засунуть внутрь if():
static void bleh(void)
{
struct foobar *f;
struct bar *b;
int i, ret;
if (!(f = foobar_new()))
errx(1, "cannot create f");
if (!(b = bar_new()))
errx(1, "cannot create b");
for (i = 0; i < b->nr_somethings; ++i)
if (ret = f->ops->do(&b->somethings[i]))
errx(1, "cannot do something: %d", ret);
foobar_free(f);
bar_free(b);
}
В C23 появился auto и теперь все ваще хорошо:
Я бы не сказал. Теперь, чтобы узнать, какого типа переменные f и b, придётся искать прототипы нужных функций, которые в общем случае (если человек видит этот код в первый раз, например) неизвестно где. Хотя конкретно у тебя эти функции выглядят как конструкторы динамических структур и тип скорее всего можно угадать, но в общем случае это не так. А ещё может так случиться, что тип возврата какой-то функции поменяют вместе с семантикой её использования вообще, рассчитывая на то, что в местах, где он используется, код сломается, компилятор выдаст ошибку и всё можно будет поправить, но из-за auto этого не случится и в коде появится баг.
Исправление firkax, :
Если брать только этот кусок сферически в вакууме, то читаемость и правда не сильно изменилась - он и так и так максимально простой. Но когда такого кода тысячи и десятки тысяч строк, это утомляет. Собственно, конкретно программа автора может быть оформлена как угодно, хоть без форматирования вообще - она и так и так простая, но лучше сразу привыкать к хорошему оформлению.
А ещё в первом присваивание можно засунуть внутрь if():
static void bleh(void)
{
struct foobar *f;
struct bar *b;
int i, ret;
if (!(f = foobar_new()))
errx(1, "cannot create f");
if (!(b = bar_new()))
errx(1, "cannot create b");
for (i = 0; i < b->nr_somethings; ++i)
if (ret = f->ops->do(&b->somethings[i]))
errx(1, "cannot do something: %d", ret);
foobar_free(f);
bar_free(b);
}
В C23 появился auto и теперь все ваще хорошо:
Я бы не сказал. Теперь, чтобы узнать, какого типа переменные f и b, придётся искать прототипы нужных функций, которые в общем случае (если человек видит этот код в первый раз, например) неизвестно где. Хотя конкретно у тебя эти функции выглядят как конструкторы динамических структур и тип скорее всего можно угадать, но в общем случае это не так. А ещё может так случиться, что тип возврата какой-то функции поменяют вместе с семантикой её использования вообще, рассчитывая на то, что в местах, где он используется, код сломается, компилятор выдаст ошибку и всё можно будет поправить, но из-за auto этого не случится и в коде появится баг.
Исходная версия firkax, :
Если брать только этот кусок сферически в вакууме, то читаемость и правда не сильно изменилась - он и так и так максимально простой. Но когда такого кода тысячи и десятки тысяч строк, это утомляет. Собственно, конкретно программа автора может быть оформлена как угодно, хоть без форматирования вообще - она и так и так простая, но лучше сразу привыкать к хорошему оформлению.
А ещё в первом присваивание можно засунуть внутрь if():
static void bleh(void)
{
struct foobar *f;
struct bar *b;
int i, ret;
if (!(f = foobar_new()))
errx(1, "cannot create f");
if (!(b = bar_new()))
errx(1, "cannot create b");
for (i = 0; i < b->nr_somethings; ++i) {
if (ret = f->ops->do(&b->somethings[i]))
errx(1, "cannot do something: %d", ret);
}
foobar_free(f);
bar_free(b);
}
В C23 появился auto и теперь все ваще хорошо:
Я бы не сказал. Теперь, чтобы узнать, какого типа переменные f и b, придётся искать прототипы нужных функций, которые в общем случае (если человек видит этот код в первый раз, например) неизвестно где. Хотя конкретно у тебя эти функции выглядят как конструкторы динамических структур и тип скорее всего можно угадать, но в общем случае это не так. А ещё может так случиться, что тип возврата какой-то функции поменяют вместе с семантикой её использования вообще, рассчитывая на то, что в местах, где он используется, код сломается, компилятор выдаст ошибку и всё можно будет поправить, но из-за auto этого не случится и в коде появится баг.