PPP Pseudocode No more, No Less

After a lot of discussions or you can say fights for about 2.5 years with Colleagues in the Software Construction field about the benefits of Pseudocode I became Balanced, moderate and fair, for that I publish this post.

The PPP (Pseudocode Programming Process) defines a specific approach to using pseudocode to streamline the creation of code within routines.

Here are guidelines for using pseudocode effectively:

• Use English-like statements that precisely describe specific operations.
  
• Avoid syntactic elements from the target programming language.
  
• Write pseudocode at the level of intent. Describe the meaning of the approach rather than how the approach will be implemented in the target language.
  
• Write pseudocode at a low enough level that generating code from it will be nearly automatic. If the pseudocode is at too high a level, it can gloss over problematic details in the code. Refine the pseudocode in more and more detail until it seems as if it would be easier to simply write the code.
  

The PPP Life Cycle

1. Write the pseudocode
   

   The pseudocode will be used shortly as the basis for programming-language code, Start with the general and work toward something more specific.
   

   The most general part of a routine is a header comment describing what the routine is supposed to do. Trouble in writing the general comment is a warning that you need to understand the routine's role in the program better.
   

   After you've written the general comment, fill in high-level pseudocode for the routine.
   

2. Check the pseudocode
   

   - Take a minute to review the pseudocode you've written. Back away from it, and think about how you would explain it to someone else.
   

   - Ask someone else to look at it or listen to you explain it
   

   - Make sure you have an easy and comfortable understanding of what the routine does and how it does it
   

3. Try a few ideas in pseudocode, and keep the best (iterate)
   

   If you're not sure how to code something, keep working with the pseudocode until you are sure. Keep refining and decomposing the pseudocode until it seems like a waste of time to write it instead of the actual code.
   

Once the pseudocode is written, you build the code around it and the pseudocode turns into programming-language comments. This eliminates most commenting effort.

Wishy-Washy names

Naming the routine might seem trivial, but good routine names are one sign of a superior program and they're not easy to come up with. In general, a routine should have a clear, unambiguous name. If you have trouble creating a good name, that usually indicates that the purpose of the routine isn't clear. A vague, wishy-washy name is like a politician on the campaign trail. It sounds as if it's saying something, but when you take a hard look, you can't figure out what it means. If you can make the name clearer, do so. If the wishy-washy name results from a wishy-washy design, pay attention to the warning sign. Back up and improve the design.