I have a code fragment which goes like this:
define buffer bfCompileSubUnit for CompileSubUnit.
create bfCompileSubUnit.
assign
bfCompileSubUnit.chID = guid
bfCompileSubUnit.chName = ""
bfCompileSubUnit.chType = "ProgramRoot"
bfCompileSubUnit.chCompileUnitID = chCompileUnitID
.
The *intention* was that chCompileUnitID was a variable defined at the class level which would get assigned from the current CompileUnit.chID when that record was created. However, it turned out in this particular program that not only was this assignment not done, but the variable was never defined. So, why did this compile? From the XREF, it appears that it resolved chCompileUnitID as the field in CompileSubUnit, i.e., assigning a field to itself.
Seems peculiar.
It's the same as
FIND FIRST Customer.
ASSIGN CustNum = CustNum .
In doubt, when no local variable is found, the ABL assumes unqualified (with a buffer Name) field name references.
That's why, I use type prefixes on variables - but not on DB fields.
It's been like that for at least 26 years.
I suppose the issue in my naming scheme, which is derived from Peter Headland's, is that compile unit level variables have no prefix. E.g., method scope variables are mch, but class level are just ch. If compile unit level variables also had a prefix, then this wouldn't happen. Bit of a bugger to change now, though, although I guess this is a good reason to do so.
To me you have just proven that you should rethink your DB field namings:
Either with a prefix like f for field or no prefix at all.
bfCompileSubUnit.fchName or
bfCompileSubUnit.Name
but never
bfCompileSubUnit.chName
And, why, exactly, do you find that compelling? Seems to me, that, if anything, the column name in the DB is the base and everything else is derivative so the derivative should have the prefix. One of the pluses of the prefix in the dictionary is greatly reducing the likelihood of a conflict with a reserved word in a future version. There was a period a number of years ago where I was prefixing the table name with tb for that reason, but I seem to have fallen away from that. The more I think about it, the idea of a prefix which means scope is compile unit makes a lot of sense ... it just isn't what Peter did lo those many years ago.
I believe that good-old Prolint should catch that with rule "tablename". Actually it warns that field "chCompileUnitID" is not fully qualified with a tablename - which implies that "chCompileUnitID" resolves to a buffer-field and not to a parameter or variable.