For people who think a little differently (like me), it works the other way around, too. I think bottom-up: from the bottom of the eventual call stack upward. Thus, I will plan out my approach, sometimes stub out my top-level function like you did, and then begin to build the lowest level functions first.
By way of example, when I wrote Omission, I followed this basic workflow:
Create bare minimum to display a message - basically a modified "hello, world!" I did not start with the UI yet!
On paper, jot down the eventual call order. I knew the game would need the content generator for anything to work, so I'd start there. I could temporarily hardcode source content in, instead of loading from a file, so I did that. I got the program to just display some generated content.
Next I added code to load content from a file. Nothing fancy here, I was only wanting to replace the hardcoded source content with material from a text file.
Now I needed interaction, so I wrote the code to allow a user to answer, and for the game to verify that answer. Again, I was still only using a text-based interface. Once I had that, I added scoring. I now had a technically functional command line game.
Now I added the timing-based functions. I didn't need to see any fancy timers, just to make sure the score reflected how long I took to answer.
To get decent further progress, I needed the GUI, so I constructed just the gameplay screen. Don't get hung up on menus at the start!
I only allowed myself to get the interface to work with the game as it existed. Once that worked...
I began to tweak and improve the gameplay and interface to be closer to what I imagined, working in much the same manner as before: plan it out, write the lowest part first, and work my way up.
Finally, I went back and added the other functionality: menus, additional gameplay modes, etc.
I'm oversimplifying, obviously, but you get the idea.
By working in this manner, I had the advantage that all my code was technically correct as I worked.
Now, a DISCLAIMER: If you think in the top-down described in the article, you probably shouldn't use my workflow. If you aren't a bottom-up programmer, this method is likely only going to confuse you. I intended this only for people who think like me. I merely wanted to show that the author's basic approach works in either direction.
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
This is actually really good advice!
For people who think a little differently (like me), it works the other way around, too. I think bottom-up: from the bottom of the eventual call stack upward. Thus, I will plan out my approach, sometimes stub out my top-level function like you did, and then begin to build the lowest level functions first.
By way of example, when I wrote Omission, I followed this basic workflow:
Create bare minimum to display a message - basically a modified "hello, world!" I did not start with the UI yet!
On paper, jot down the eventual call order. I knew the game would need the content generator for anything to work, so I'd start there. I could temporarily hardcode source content in, instead of loading from a file, so I did that. I got the program to just display some generated content.
Next I added code to load content from a file. Nothing fancy here, I was only wanting to replace the hardcoded source content with material from a text file.
Now I needed interaction, so I wrote the code to allow a user to answer, and for the game to verify that answer. Again, I was still only using a text-based interface. Once I had that, I added scoring. I now had a technically functional command line game.
Now I added the timing-based functions. I didn't need to see any fancy timers, just to make sure the score reflected how long I took to answer.
To get decent further progress, I needed the GUI, so I constructed just the gameplay screen. Don't get hung up on menus at the start!
I only allowed myself to get the interface to work with the game as it existed. Once that worked...
I began to tweak and improve the gameplay and interface to be closer to what I imagined, working in much the same manner as before: plan it out, write the lowest part first, and work my way up.
Finally, I went back and added the other functionality: menus, additional gameplay modes, etc.
I'm oversimplifying, obviously, but you get the idea.
By working in this manner, I had the advantage that all my code was technically correct as I worked.
Now, a DISCLAIMER: If you think in the top-down described in the article, you probably shouldn't use my workflow. If you aren't a bottom-up programmer, this method is likely only going to confuse you. I intended this only for people who think like me. I merely wanted to show that the author's basic approach works in either direction.
That’s a really good juxtaposition of the two methods. It is interesting seeing how much they have in common!