Believe it or not, there are actually programmers who advocate using the latest technologies yet continue to do one very amateurish thing. Can you guess what it is?

Let's start with what is often advocated by the leading-edge programmers: long field names and free-format. Both of these are good features to have in a programming language and should be used when people are comfortable using them or when a shop standard is in place that advocates either.

With RPG IV, using long variable names is nearly as easy as in any other programming language. Granted, we have our share of obscurities, but it is fairly benign to name a field something like COMPNAME, COMPANY_NAME, or even, CUSTOMER_COMPANY_NAME. Compare that with CMPNAM or CSTNAM used in pre-RPG IV days.

Regardless of whether using CUSTOMER_COMPANY_NAME as a specific variable name is a good idea, the fact is that in RPG IV it is considered a contemporary programming practice. The use of longer, more descriptive variable names in source code is preferred over the passé six-character variable names to which we were previously limited.

Of course, advocating free-format a la the /FREE specification in RPG IV is a common characteristic of those who also advocate long field names. After all, how do you fit those long field names into the traditional extended Factor 2 C-spec of an EVAL opcode and also include any other expression symbols?

I'm still not a fan of the /FREE specification; however, I no longer hate it as I once did. There are far too many other things to resent in RPG IV. For now, I view /FREE as most countries view their own atomic weapons stockpile: It is a powerful tool that I hope I never have to use.

Is That Packed or Zoned?

But herein lies the irony: Many RPG IV programmers who advocate /FREE and/or long variable names tend to avoid specifying data types on field declarations.

What's very interesting to me is that if they can type in CUSTOMER_COMPANY_NAME, why then can they not enter 3P0 if they mean packed or 3S0 if they mean zoned? Quick, what type of field is 3 0?

To be honest, I can't even tell you what type of field it is. Why? Because I don't care. If you want me to be able to read your code and make accurate changes, then put in the darn data type, you lazy coder.

Here are three examples of what happens when you do not use the data type in your code:

Input Specifications

In this example, the CUSTNO field is defined as what? Zoned decimal. The COMPNAME field is character.

Data Structure Subfields

In this example, the CUSTNO subfield is defined as zoned decimal, and the COMPNAME field is character.

Standalone "Work" Fields

Now, in this example, CUSTNO is defined as packed decimal, and COMPNAME is, of course, character.

If you were a good programmer, you would (A) not know this and (B) have written the code as follows:

Of course, you probably really meant that the field was packed or zoned in all situations. So perhaps the following would be more appropriate:

Actually, there's something missing from the above examples; the COMPNAME data type is blank. Let's fix that.

Now this is how you should be writing code!

Regardless of the fact that numeric data structure subfields without a data type default to zoned decimal, while numeric standalone fields default to packed (number 18 on my list of dumb things IBM built into RPG IV), there is absolutely no reason for programmers to omit the data type from a field. Please excuse me if I'm being rude, but doing so really shows how lazy you are. And think about this: If I'm looking at your code and assume that a typeless numeric variable is packed, I could spend hours or even days looking in the wrong place for a bug.

So don't be lazy! Write good code!