Why Parameter_name and renaming of Srvroutines

[atostaine]

Does renaming fields in field maps and renaming server routines make code better? i realize they are optional but what are most developers doing?

[Stewart Marshall]

For me, this is all about readability and the meaning of code. Specific variable names IMO are really only relevant when you're forced to use them, which is only when dealing with the database.

Parameter_Name was introduced for a couple of reasons to do with this.

Firstly, Group_Map and List_map expose locally defined variables whose name may not be particularly descriptive or helpful.
Secondly, fields on a map are often generic or poorly named (particularly old 6 char DDS), so being able to given the map a more understandable name helps other developers when they come along in the future. They also show when you view them in the feature viewer (F2)

If you code calls to server routines as I do using short notation, you get no real immediate benefit

Code: Select all

Define_Com Class(#SrvModule.GetEmployees) Name(#GetEmployees)
#GetEmployees.ExecuteAsync(#Employees)

but if you prefer to see parameter names, it certainly adds value and aids comprehension to have a nice English name for the variable.

Code: Select all

Define_Com Class(#SrvModule.GetEmployees) Name(#GetEmployees)
#GetEmployees.ExecuteAsync EmployeeList(#Employees)

The same applies when using field names on Define_Maps for methods. I often see them defined with a Name exactly the same as the cryptic field used as the class. All well and good if you're familiar with the field names, but so much simpler and clearer to take the time to write in English IMO.

[atostaine]

I see your reasoning. One would need a shop standard so that all developers always name "#CNAD1" to "ConsigneeAddress1". I could see developers spelling it wrong or using "ConsigneeADR1", etc.

Thank you.