A Word or Two, or More, on Coding Standards

April 5th, 2008

Some programmers groan at them (what another way to do the same thing?!), some programmers believe that they know all they need to know about coding (why they have been coding for 10, 20, or 30 years this way and it works) and some programmers readily adapt their style to the IT department’s coding standard because they know and understand the value it means to the department and to the company.

One of the things that I have found in my career as an application developer is that there is an absolute need to have each programmer within the company following the coding standards and practices of the IT department. Even if those standards don’t seem to make sense. I have worked in IT departments where they had loose standards, no defined standards and rigid standards. To my surprise, I found that I prefer the rigid.

I am sure that you work at companies where you found yourself the proud owner of someone else’s code. And you were told that you needed to update the program to do something more. When you opened up the code, you were stunned and bewildered, because what was inside had no resemblance of structure, order, or a naming convention that you were used to. So what did you do? Most likely, rewrite it in the structure that you were used to which takes up time, money, and a special irritation from you know who when you tell him or her that it will take 2 or 3 times as long as they had expected.

Now, I have usually worked with commercial packages and they have rigid coding standards because they need their programmers to act as one programmer doing the similar things in the same way. In this way, any programmer can step into the code and make a change in the correct place without having to learn the entire program from top to bottom. This saves time, aggravation, and especially money.

I know money is not something that some programmers are concerned about because far too often they think that they don’t get enough of it. But the truth is, programmers are more often viewed as an expense and not an asset to the company. It is not a good thing to be viewed as expense when the budget is tight, but if you show that you save the company money by following the standards, you will become an asset. As an asset with the knowledge of the standards, you will be valuable to them.

So when you are out there, try actively adopting and promoting standard coding practices of the company that you work for, even if you don’t agree all of the time.

All content is ©2007 Gregory D. Stoltz unless otherwise specified. All Rights Reserved. To request permission to reprint an article or tip, please contact greg@superior-rpg.com.

RPG Tip: %EQUAL

April 5th, 2008

If you are like me, you like to save time by using clever ways to prevent typing repetitive code if it can avoided. I have found that using the %EQUAL built-in function works nicely if you have to archive or log changes to a particular file.

%EQUAL does not require you to type every single field when the archive file has the same the field names. It works better than using an indicator because of the time trying to make sure the indicator is in the correct column or having the indicator get changed elsewhere in the program. With the built-in function %EQUAL, no guess work is needed when using it with SETLL or LOOKUP which makes it self-evident to what it is doing and ultimately saves time.

Example code: Use the %EQUAL built-in function when archiving data- base records in two different files which use nearly all of the same fields without renaming any fields. This eliminates the need to remember to set fields in the program when the ITEMMAST file changes.

C*
C* Archive changes.
C*
C ITEM CHAIN ITEMMAST
C IF %FOUND
C ITEM SETLL ITEMARCH
C IF NOT %EQUAL
C …. Set unique archive fields here
C WRITE RITMARCH
C ENDIF
C ENDIF
C*

All content is ©2007 Gregory D. Stoltz unless otherwise specified. All Rights Reserved. To request permission to reprint an article or tip, please contact greg@superior-rpg.com.