What are Pre-conditions and Post-Conditions in Programming?

I briefly mentioned in my post titled What is Top-down Design and Stepwise Refinement? about pre-conditions and post-conditions. In this post I want to explain the two essential points in greater detail.

These two principles are one of the keys to being effective in programming.

What are Pre-conditions?

Lets start with the first of the two which is titled pre-conditions. A pre-condition in its most simple form is a condition that needs to be “true” for a method to be called. This means that the method you are calling is expecting something to be in place before or at the point of the method being called.

Putting this in the context of Karel again, we might have a method that collects beepers in a tower. A pre-condition could be that Karel needs to be at the base of the tower facing east. If this pre-condition is true when the method is called, then Karel will move up the stack as expected and collect all the beepers. If the condition was not true and Karel was facing north then the method would end up turning Karel to face west and he would go the wrong way to collect beepers, potentially crashing in the process.

Of course, when a method comes to an end, some post-conditions need to be set. Explanation below:

What are post-conditions?

So, a post-condition is effectively what conditions the method will finish up with. If collecting a tower as in the example above, one of those post-conditions might be to return Karel to the ground and turn him to face east in preparation for the next instruction after this method comes to an end.

In doing this, you are letting the next method know what to expect. If the post-condition closes as true then the next method will know exactly where to move next.

Pre-conditions and post-conditions are not too complicated in the early days. You just need to make sure you watch out for them. When designing programs you might forget about one of these, such as the post-condition, and when the next method runs you might end up sending Karel to the wrong location on the screen.

How to Avoid Changing Pre-Condition Requirements

Although our method might have a pre-condition attached such as… Karel needs to be facing east, we could also go a little more advanced and actually put some error checking in place at the beginning of our method. Karel had 8 commands relating to this which are:

facingNorth()
facingSouth()
facingEast()
facingWest()
notFacingNorth()
notFacingSouth()
notFacingEast()
notFacingWest()

Just to avoid errors when someone else is calling our method, we might want to put a check in place that says if (notFacingEast()) { and if Karel is not facing the right direction, work out which way he is facing and turn him the right way. We could even go a step further and use the leftIsClear() method or rightIsClear() method to check if Karel is on the ground and if not, move him there. After all error checks are done, we can then proceed with the method.

This part goes a little beyond Karel and your first assignments though, but it’s handy to know that you can error check and can either pass back an error message or correct the error within your own method.