Comment by flir
1 day ago
Interesting. I wouldn't be able to keep that straight in my head - I wouldn't be able to predict all the low-level functions I needed until I'd built the higher-level functions. In fact I'd approach it exactly backwards - start at the top and work my way down. It matches perfectly with a Jackson Structured Programming diagram in my mind.
Build main() by decomposing it into calls to input(), process(), output(). At each step decompose the function you're working on, handing as much of its work as possible off to a child function you haven't yet written. Only question after that is whether you implement those functions depth-first or breadth-first (I'd prefer depth-first).
Maybe procedural programming is now so old it's novel again.
I find it's easy enough to adapt to - and switch between - either convention, as long as there is indeed a convention.
What really hurts readability for me is when the structure is a random mix of top-down and bottom-up. Which seems to be regrettably common in many object-oriented codebases.