The Pseudocode Programming Process

Slides for a talk I gave on pseudocoding

Transcript

1. The Pseudocode Programming Process
2. Pseudocode • Informal, English (or whatever your native language is)-like notation to describe the process that you are trying to code.
3. The Process Begin Design the routine Check the design Code the routine Review and test the code Profit
4. Do Not Pseudocode In Your Programming Language GOOD BAD • This makes reviewing your high level approach to the problem much easier. • You don’t have to review the code itself until you are happy with the much easier to read and conceptualize pseudocode.
5. Pseudocode Encourages Iteration • Your first solution probably sucks. • Pseudocoding it out takes much less investment in your initial solution than writing the code and/or tests for the code. • You are more likely to review your proposed solution before being waist deep in a messy solution. • Being able to say your solution in English will make it easier to bounce ideas off of friends. They don’t want to spend hours reading your code.
6. More Pros • Your code is documented before you write it. Comments will be easier to write, and if you get lost or distracted while coding the solution, you have a guide to get you back on track. • You will learn to speak to non-tech people better.
7. Step 1: Design the Routine • Define the problem you are trying to solve. • You can start with just 1 sentence describing what the routine is supposed to do. • Iterate over your pseudocode, expanding on it, until it feel like code will naturally flow from what you’ve written.
8. Step 1: Design the Routine • Check the prerequisites. Are there any conditions that need to be met before this routine runs? • What inputs will you need? • What will the outputs be? • Are there postconditions that the routine guarantees to be true.
9. Step 1: Design the Routine • Give the routine a good name. If you can’t name it well, you haven’t defined the problem well enough. • How will it be tested? • Is there a library you can use that does a lot of the heavy lifting for you? • How will you handle errors? • What is the Big O?
10. Step 1: End • Go forth my children, and write pseudocode
11. Step 2: Check the design • Check it good. • Having multiple projects on the burner can help with this. • Once you define a problem and write good pseudocode, you can let it simmer and move onto another project or another part of that project. • Stepping away and coming back to the pseudocode will allow you to approach it with fresher eyes. It is difficult to see new ways to do something when you’re in the middle of it.
12. Step 2.5: Check it again • “Rubber ducking” is a good idea • Explain it to a friend/co-worker
13. Step 3: Code the routine • You may feel ready to knock this problem out of the park, but, being in the middle of coding it, you may realize you missed out on something. • Don’t be afraid to step back; fix your pseudocode; and start again or make adjustments
14. Step 3.5: Clean Up • Clean up your code. Do not EVER commit messy code. Take the time to clean up after yourself. • “Messy code, messy mind” • Check your code to your pseudocode. Does it match up? Did you miss anything?
15. Step 4: Review and Test • How do you like your solution? • Does it need refactoring? • Write tests to prove the code works as intended. • Test for edge cases. • Note: testing is a very extensive topic, so please stop me if I start ranting.
16. Profit • Well designed code has less bugs. • Your boss makes more money • You get a raise • World peace
17. Questions?