For me, Pseudo coding feels like a waste of time. Should I really do this always, or is a flow chart enough?
It’s not necessary. But if you are doing something complicated, writing the function in English first could help you think it through before you write the code
Also, if you work with a group of people and have unfinished functions, PsedoCode can show other people what you are planning to do with them.
3 Likes
Honestly, you can do any sort of planning technique you want or none at all!
The main reason why you’d want to do psuedocode, though, is if you’re working with other programmers in a team. It makes for a great way to communicate what your code is (or will, if unfinished) doing. It’s an industry standard way of organizing and documenting code.
Some will argue that all code should be “self-documenting”, but in practice not only does that not happen but it’s pretty much impossible to do 100% of the time.
3 Likes
Thank you for your quick answer!
OMG, thank you! This community is just awesome!
1 Like
I also feel that it is a bit of a waste of time lol
I’m going to precede my answer with saying that Mikapo and Tuomo_Taivainen hit on a lot of really good points here. The short answer is “technically, no” with a huge caveat. Jumping straight into development is sometimes called “cowboy coding” and is a notoriously bad idea because there’s little direction on how to proceed. I firmly believe designing a program is necessary to complete a quality product.
I had a professor for an introductory programming course in my undergraduate studies once say that your time spent on development should be 20% design, 60% development, and 20% debugging. Later on, I had a different professor for a software architecture course correct that philosophy by emphasizing design. The second professor stated that if you emphasize the amount of time spent on design, ex: 50% design rather than 20%, you can shrink the debugging time to almost 0%. Obviously, stuff happens and bugs arise out of nowhere, but the point still stands. I took that course ~6 years ago and have held onto this philosophy ever since.
So, to directly address the original question, the EASIEST way to begin designing a program is through the methods shown in the video:
- Pseudocode
- Flowchart
- Writing a story / user stories (this was moreso previous videos)
Doing this gives you a chance to really sit and think on how you want the program to look as a whole. From there, you can revisit and refine the details in an iterative process. This design may change as you proceed (again, as shown) but it gives you a plan to fall back on as you develop.
2 Likes