I'd hazard to guess that everyone got their own process ranging from "seat of pants" improvised to "t's crossed and i's dotted" pre-planned.
I think best visually, so I sketch out how screens are supposed to look like - and how data is supposed to flow. From there on in, I set up the skeleton of how the app is organized, and flesh it out as I proceed. So plenty of empty functions in the start, with some comments on what it is supposed to do and perhaps a little print() just to notify that it is visited during run-time.
I also tend to spread my code over several files - where each have a certain responsibility. For instance:
- main : The initial setup and boilerplate stuff
- view : Organizing and displaying the various screens
- output : Nuts and bolts of displaying graphics
- text : Nuts and bolts of displaying Text
- input : Nuts and bolts of receiving user input
- fileIO : Saving and loading files
- httpIO : Sending and receiving to and from backend server
- structs : Where all datatypes are defined
- constants : Where all immutable data is filled in
- tests : Automated tests where necessary. I'm not religious about TDD
In the end though, it is all up to personal preference and experience. You develop your 'style' and process as you go - there is no correct recipe or secret to it.
There is one best-practice you should follow though, and that is what often is called clean code. In short:
- Have good explanatory variable, type and function names
- Be consistent in any naming and style choices
- Immutable can be free, mutable must be controlled
- Keep functions small, managing just the one thing or have just the one responsibility
- Don't repeat yourself
- If you keep your data well organized, functions nearly write themselves
- Simple is better than complex
- Readable is better than clever
