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.

Box-and-line drawings are not architectures at all

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

An architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements.

The behavior of each element is part of the architecture insofar as that behavior can be observed or discerned from the point of view of another element. Such behavior is what allows elements to interact with each other, which is clearly part of the architecture.

All nontrivial projects are partitioned into implementation units; these units are given specific responsibilities and are frequently the basis of work assignments for programming teams. This type of element comprises programs and data that software in other implementation units can call or access, and programs and data that are private.

Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system's function.

Are any of these structures alone the architecture? No, although they all convey architectural information. The architecture consists of these structures as well as many others.

We do not mean that the exact behavior and performance of every element must be documented in all circumstances; however, to the extent that an element's behavior influences how another element must be written to interact with it or influences the acceptability of the system as a whole, this behavior is part of the software architecture.

[From Software Architecture in Practice, Second Edition]

You're turning into a dinosaur

If your workload consists entirely of short-term assignments that don't develop your skills, be dissatisfied. If you're working in a competitive software market, half of what you now need to know to do your job will be out of date in three years. If you're not learning, you're turning into a dinosaur.

The Humble Programmer

At the 1972 Turing Award Lecture, Edsger Dijkstra delivered a paper titled "The Humble Programmer." He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren't equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you'll be. The more humble you are, the faster you'll improve.

Logical cohesion vs Event handler

Logical cohesion occurs when several operations are stuffed into the same routine and one of the operations is selected by a control flag that's passed in. It's called logical cohesion because the control flow or "logic" of the routine is the only thing that ties the operations together—they're all in a big if statement or case statement together.

Event Handler: the routine's only function is to dispatch commands and it doesn't do any of the processing itself, that's usually a good design. The technical term for this kind of routine is "event handler." An event handler is often used in interactive environments such as the Apple Macintosh, Microsoft Windows, and other GUI environments.

Operating-room technique

Data is sterilized before it's allowed to enter the operating room. Anything that's in the operating room is assumed to be safe. The key design decision is deciding what to put in the operating room, what to keep out, and where to put the doors—which routines are considered to be inside the safety zone, which are outside, and which sanitize the data. The easiest way to do this is usually by sanitizing external data as it arrives, but data often needs to be sanitized at more than one level, so multiple levels of sterilization are sometimes required.

Hide Secrets (Information Hiding)

Information hiding is part of the foundation of both structured design and object-oriented design. In structured design, the notion of "black boxes" comes from information hiding. In object-oriented design, it gives rise to the concepts of encapsulation and modularity and it is associated with the concept of abstraction. Information hiding is one of the seminal ideas in software development, and so this subsection explores it in depth.

Two Categories of Secrets

Secrets in information hiding fall into two general camps:

• Hiding complexity so that your brain doesn't have to deal with it unless you're specifically concerned with it
  
• Hiding sources of change so that when change occurs, the effects are localized
  

  (Steve McConnell)
  

Experimental Prototyping Risk

A Big risk of prototyping arises when developers do not treat the code as throwaway code. I have found that it is not possible for people to write the absolute minimum amount of code to answer a question if they believe that the code will eventually end up in the production system. They end up implementing the system instead of prototyping. By adopting the attitude that once the question is answered the code will be thrown away, you can minimize this risk. One way to avoid this problem is to create prototypes in a different technology than the production code. You could prototype a Java design in Python or mock up a user interface in Microsoft PowerPoint. If you do create prototypes using the production technology, a practical standard that can help is requiring that class names or package names for prototype code be prefixed with prototype. That at least makes a programmer think twice before trying to extend prototype code (Stephens 2003).

V-Model

The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing

The V-model can be said to have developed as a result of the evolution of software testing. Various testing techniques were defined and various kinds of testing were clearly separated from each other which led to the waterfall model evolving into the V-model. The tests in the ascending (Validation) hand are derived directly from their design or requirements counterparts in the descending (Verification) hand. The ‘V’ can also stand for the terms Verification and Validation.

V-Model is more helpful and profitable to companies as it reduces the time for whole development of a new product and can also be used to some complex maintenance projects.

Reference: V-Model

ABC

What is the relationship of a system's software architecture to the environment in which the system will be constructed and exist? The answer to this question is Software architecture is a result of technical, business, and social influences. Its existence in turn affects the technical, business, and social environments that subsequently influence future architectures. We call this cycle of influences, from the environment to the architecture and back to the environment, the Architecture Business Cycle (ABC).

Complicated Casts

It is easy to cast something to an elementary type:
write the name of the new type (for example, int) in brackets before the expression you wish to cast.
It is not quite so obvious how to cast to a more complicated type.
Say you have a pointer to a void that you know actually contains a function pointer.
How do you do the typecast and call the function all in one statement?

Even complicated casts can be written following this three-step process.
1. Look at the declaration of the object to which you wish to assign the casted result.
2. Remove the identifier (and any storage class specifiers like extern), and enclose what
remains in parentheses.
3. Write the resulting text immediately to the left of the object you wish to cast.

Good C Puzzle

What will be the output of this program?!

main()
{
int a=3, b = 5;

printf(&a["Ya!Hello! how is this? %s\n"], &b["junk/super"]);
printf(&a["WHAT%c%c%c  %c%c  %c !\n"], 1["this"],
2["beauty"],0["tool"],0["is"],3["sensitive"],4["CCCCCC"]);
}

The Two Hats

When you use refactoring to develop software, you divide your time between two distinct activities: adding function and refactoring. When you add function, you shouldn't be changing existing code; you are just adding new capabilities. You can measure your progress by adding tests and getting the tests to work. When you refactor, you make a point of not adding function; you only restructure the code. You don't add any tests (unless you find a case you missed earlier); you only restructure the code. You don't add any tests (unless you find a case you missed earlier); you only change tests when you absolutely need to in order to cope with a change in an interface.

As you develop software, you probably find yourself swapping hats frequently. You start by trying to add a new function, and you realize this would be much easier if the code were structured differently. So you swap hats and refactor for a while. Once the code is better structured, you swap hats and add the new function. Once you get the new function working, you realize you coded it in a way that's awkward to understand, so you swap hats again and refactor. All this might take only ten minutes, but during this time you should always be aware of which hat you're wearing.