Looking  back, I have covered most topics that I wanted to discuss so far. The presentation has not gone exactly in the way planned. However, this is the time to offer the summary. This summary is written with a refactory point of view.

1. There are two types of decisions. Existence and environment decisions AND value decisions.

2. Most bugs and inflexible designs arise because decisions are spread in the design and the code.

3.  Make sure all “not”s are substituted by “if-else”s. Break decision clauses into larger chain of conditions if needed.

4. Convert all “equality” value “if-else if-else” into switch-cases. Split all “inequality” value “if-else if-else” into explicit rule base and simplify the implementation.

5. Once rule base is separated, try to convert as many switch-cases into function pointers as possible. This is going to separate “what” from “how” and will keep errors limited to  “what” parts. If you reach this step, most of your program will function without bugs and maintenance will start becoming easy.

6. If you are allowed to take a step further, see that the function pointer array that was generated in previous statement is nothing but class heirarchy. Convert them to sub classes. At this point you should see a collapse in the “how” code size and a drastic reduction in number of bugs.

7. If you are still allowed to take a step further, you are at door steps of aspect oriented programming. At this moment, you will be able to see environment variables changing the behavior across classes.  This is the time to write cross-cutting concerns and eliminate further bugs and induce further versatality in the code

8. Make sure your next code starts with these ideas followed rigidly. Introduce these ideas as check marks in code review. [e.g. “All possible if’s are converted into switches”, “all possible switches are converted into function pointers”, “all function pointers are converted into subclasses with inherited interface”,  …]

9. And yes, participate in language design issues and favor introduction of switch like control structures, associative arrays, late bindings, OO and AO – dependent on the context of the language.

My next series will be on testing algorithms. Until then, good bye!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s