LINUX.ORG.RU

История изменений

Исправление 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);
}
И в таком виде читаемость уже заметно лучше: каждый условный оператор сразу показывает, какое выражение мы проверяем, не надо возвращаться глазами на строчку вверх после того как видишь if. И в целом: теперь весь код по сути влезает в 3 хорошо различимых и тривиальных строчки (если убрать переносы строк после for() и if()) + 2 строчки с чисткой, а в оригинале он выглядел как алгоритм.

В 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);
}
И в таком виде читаемость уже заметно лучше: каждый условный оператор сразу показывает, какое выражение мы проверяем, не надо возвращаться глазами на строчку вверх после того как видишь if. И в целом: теперь весь код по сути влезает в 3 хорошо различимых и тривиальных строчки + 2 строчки с чисткой, а в оригинале он выглядел как алгоритм.

В 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);
}
И в таком виде читаемость уже заметно лучше: каждый условный оператор сразу показывает, какое выражение мы проверяем, не надо возвращаться глазами на строчку вверх после того как видишь if.

В 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);
}
И в таком виде читаемость уже заметно лучше: каждый условный оператор сразу показывает, какое выражение мы проверяем, не надо возвращаться глазами на строчку вверх после того как видишь if.

В C23 появился auto и теперь все ваще хорошо:

Я бы не сказал. Теперь, чтобы узнать, какого типа переменные f и b, придётся искать прототипы нужных функций, которые в общем случае (если человек видит этот код в первый раз, например) неизвестно где. Хотя конкретно у тебя эти функции выглядят как конструкторы динамических структур и тип скорее всего можно угадать, но в общем случае это не так. А ещё может так случиться, что тип возврата какой-то функции поменяют вместе с семантикой её использования вообще, рассчитывая на то, что в местах, где он используется, код сломается, компилятор выдаст ошибку и всё можно будет поправить, но из-за auto этого не случится и в коде появится баг.