> -- Александр Ильин писал(а):
> Пока народ подтягивается и формирует своё мнение, добавлю следующее замечание. На мой взгляд, наибольшей ясности можно добиться грамотной декомпозицией. Например, функция read_file должна бы выглядеть примерно так:Провести такую декомпозицию невозможно до тех пор, пока в коде пристутствуют break/goto между уровнями вложенности блоков. Когда прыжки между уровнями устранены, любой вложенный уровень можно оформить в виде отдельной функции и дать ей осмысленное имя. При визуальной обозримости кода выделение в отдельную функцию может быть не обязательно, но читающий всё равно  предназначение каждого блока, в том числе в виде пред- и постусловий. Именно таковая возможность, на мой взгляд, является главным преимуществом структурной записи алгоритма.

Так как ты упомянул "грамотную" декомпозицию, то значит ли это, что упомянутый здесь ранее метод вложенных if-ов ты считаешь неприемлимым?

А потом, почему ты остановился в декомпозиции только на первом уровне, read_file_hnd?  Можно продолжить и дальше, не так ли?  Внутри read_file_hnd() создадим буфер и вызовем еще одну функцию теперь уже с четырьмя параметрами: read_file_hnd_with_buffer(fh, buffer, content, content_size).  Тут уже не так красиво получается, как хотелось бы.

Представим, что у нас последовательность действий не такая короткая, как в этом примере, а немного подлиннее, но все равно линейная:
1. получить ресурс1
2. создать ресурс2 с использованием ресурс1
3. получить ресурс3
4. создать ресурс4 с использованием ресурс2 и ресурс3
5. создать ресурс5 с использованием ресурс1
6. проделать некоторые операции с использованием ресурс3, 4 и 5.

Каждое из этих действий может завершиться с ошибкой, при которой нужно освободить все до этого полученные ресурсы, и выйти из функции.  Если следовать твоему методу с созданием дополнительных функций на каждом шаге, то на шаге 2 у тебя будет еще одна функция с одним дополнительным параметром, на шаге 3 - двумя (нужно протащить ресурс1 и 2), на шаге 4, 5 и 6 - тремя.  Допустим, что первоначальных параметра было 3, функция на последнем шаге будет иметь 6 параметров.

Все эти дополнительные функции, естественно, лишние, потому что перед нами простая, линейная последовательность действий.

Теперь допустим, что требования немного поменялись.  На шаге 3 нам не нужно больше создавать ресурс3.  Получается, что мы не только должны изменить реализацию, но и интерфейсы всех функций, которые следуют  за шагом 3.

Поэтому с практической точки зрения, твой подход не работает, или как еще можно сказать, не масштабируется: с увеличением количества шагов резко возрастает количество действий, которые программист должен проделать, чтобы написать или внести изменение в код.