Comment by userbinator
2 days ago
and you often discover, in the middle of writing your low-level functions, that your high-level functions need to be revised, which append-only programming makes difficult
On the other hand, it's not a problem if you start bottom-up, which is a natural style when writing in C; the low-level functions are at the top (and the standard headers included at the very top can be thought of as a sort of lowest-level), while main() is at the bottom.
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.