My Favorite Little Code Pattern in OutSystems

Becoming a better programmer is often a matter of small improvements rather than big leaps of experience. One area that is made up of incremental things rather a “big bang” change is the area of “coding hygiene”, the things we do to make our code clean, easy-to-read, and maintainable. One of the nicest things I have done for myself on this topic is to start using a “NotImplemented” Exception. Let me explain.

Imagine the following statement: “if A then B, else C”. All well and good. Now, in some situations, “if not A then C” may be a perfectly correct statement. But what happens when the logic changes? The problems get even worse when we are talking about a Switch! The “Otherwise” branch on a Switch can be a real problem area.

Consider a Static Entity called AnalysisStep, with three records:

• UploadFile
• VerifyDevelopers
• Results

And we have an Action that uses an input parameter of type AnalysisStep Identifier to determine an output.

Please don’t judge me for my layout here, just showing the conditions! :D

In this case, we have overloaded “Otherwise” to mean “AnalysisStepId = Entities.AnalysisStep.Results”.

“Overloading” things not designed for it is probably a bad idea.

Tests fine, works fine… what’s the problem?

Well, let’s say the manager says next week, “let’s add another value to AnalysisStep, called ‘ReviewResults’.” And the team jumps on it, adds that new record. Well… that Otherwise now actually means “AnalysisStepId = Entities.AnalysisStep.Results OR AnalysisStepId = Entities.AnalysisStep.ReviewResults”. There is a really good chance that no one will think to update this code (or any other code!) like this. OOOPS. And it isn’t throwing an exception, it is continuing to work correctly, so there is a very strong chance that the QA team will miss places where the code is not working as-expected.

Here’s the better way to handle this. Add an Exception type (I like to call it “UnimplementedException”) for this scenario. Have your Otherwise go to it. Add explicit tests in your Switch for each possible record. Now, what happens? Well, if someone hits a piece of code that wasn’t updated to handle the new record, BOOM it blows up and everyone notices really quickly that there is a problem.

Much better!

“Fail fast, fail hard” works wonders, and this is a great little pattern to ensure high quality code.

J.Ja