2E Code Review - pet hates - part II

Back again...

My intention was that the first post would cover my major pet hates...  Being the perfectionist (that I am when it comes to coding) I quickly realised that I see many more coding mistakes/habits/bad practices that irritate me.

So here are another 3 things (there are still others on the list) that "get on my goat".  I laugh inwardly because I can see each and every developers face who I associate with some of these bad habits.  I also frustratingly recall the countless times I've explained why 'xyz' is bad without achieving a behavioral change.  Stubbornness is a very special human trait.

I go back to a previous post, way way back in 2008/2009 in fact.  I state that without a declared mandate/role to reject bad code, things never change, performing code reviews by democracy simply doesn't work.  This is why I am such a fan of 'automated development standards' review technology as it takes away the conflict.

Back to the list of bad habits that are consuming me today :-)

4. Externalising a single function to get over file limits.

Ever hit the RPG 50+ file limit?  Often you will see people externalising a single RTVOBJ (for example) in order to get back to 50 files or less.  This is the most shortsighted piece of coding I ever see and will only damage your code base.  In this instance RPGLE wasn't an option but as you can tell the option for structuring wasn't taken.

Here is a rather extreme example of a (now deprecated) function from my model at work.  I have altered some of the images for privacy reasons.

Associated hates: Not only will the multiple external functions increase the call stack, reduce performance, introduce errors as people forget about passing the *Return Code back (common issue when externalising) it is only ever a short term option as applications expand significantly overtime.

There are numerous other options which I have covered before like RPG to RPGLE conversion, externalising a major block of associated logic i.e. Load, Validate or Update processing or full function refactoring etc.

Tip: My preference is to aim for a mixture of RPGLE migration and also some refactoring options for better function isolation.  This depends on how much user source you have etc.


5. BOTH parameters that are initialised from within.

Often a developer will need to total up some values across multiple records.  In 2E we would typically use a RTVOBJ to work through a set of records and increment a value.

A quick and dirty way to do this is to declare a value that you want to sum up as a both parameter.  Then within the AD (Action Diagram) the code to increment the value is PAR = PAR + DB1 and an average developer would argue that the passing of the value to the output variable via the PAR is automatic.

Their logic is sound if you are trying to keep your action diagram code to the minimum.  Look at the two example below.

The lazy way

The correct way

On the surface it looks like the lazy way is okay.  It ticks the boxes for.

• Clear function naming
• Minimal AD code (x lines vs y lines)

Then it fails miserably. 

Interface

The BOTH method's parameter interface is not as easy to decipher as the correct method.  You wouldn't know from the function interface that the field(s) being totaled are being initialised back to Zero from within.

What should happen if a value is passed in.  You would expect that the value passed in, say 100.00 would be included in the total.  Here is the confusion.  The function name and interface should clearly depict what is going in inside. 

6. Leaving the MAP on.

MAP parameters are designed to pass a value passed into a function (via parameters) and place it on a device design and automatically populate the data.  i.e. MAP the parameter value to the screen or report.  There is NO other use of the MAP role within 2E.

Leaving the MAP on internal functions like a CRTOBJ or RTVOBJ. 

Whilst not impacting code, it is a sign that the developer doesn't truly understand the role of MAP and if they do, then by leaving it on they are implying that it is satisfactory to be tardy.  To me it is like not dotting an i or crossing a t.

I am going to give the developer a little out here.  CA could make it easier by NOT setting MAP by default and making it a 'opt in' option rather than something we have to constantly switch off.


Thanks for reading.
Lee.