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.
I'm a Sr. Software Engineer at Flashpoint. I specialize in Python and Go, building functional, practical, and maintainable web systems leveraging Kubernetes and the cloud. Blog opinions are my own.
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!