Of course we all use strict naming conventions for reference keys: like employee.employeeId (never: employee.id).
But now the question:
Should You use
a. employee.employeeDescription
b. employee.employeeDesc
OR
c. employee.description
?
c.
everytime. It drives me *nuts* looking at code that has the tablename as part of the fieldname.
Why would you record a description of an employee? Is this just in case you needed to describe them to the police?
|
meh. Benefits.employeeId ;)
For this particular example, I would go with (a). It's good practice to avoid having Progress keywords as schema names (in either table or field names)
Agree with Julian and Peter both. But lets also consider the way table is named (if you're interested :-) ). In your example the name of table is employee (singular form). It would be better to name it as `employees` if you think from the point of view that the table is supposed to store records of many employees (not employee).
So reading queries also makes sense with this convention. Like
FOR EACH employees NO-LOCK WHERE employees.id <= 20:
// do something
END.
Moreover your "arguments to consider" seems good enough if you haven't had any coding conventions being followed in your team yet.
There is a GitHub page about OE coding standards which provide decent guide lines -> github.com/.../oestandards
The debate over plural or singular in table names isn't new: stackoverflow.com/.../table-naming-dilemma-singular-vs-plural-names
My personal preference goes to the singular form, as typing "for each customers" just seems wrong to me...
Which is why there are tables and buffers. The table is plural, the buffer is singular.
define buffer customer for customers.
find first customer.
Unfortunately Progress gave us a default buffer which leads to all the confusion.
Also in the case of for each, it should be singular:
for each customer where ....
end.
The plural name makes sense when working on the records as a result set, as our SQL friends do:
select * from customers.
> Which is why there are tables and buffers. The table is plural, the buffer is singular.
Is that worth a SonarQube rule ? :-)
We have lots of tables with names which needed to fit in a limited number of characters for DB2/400 or so, so it wouldn't help. :-)
Basically all tables are somehow bound to store multiple records so why bother using the plural… you might think there could be just the ‘god’ table that only have one (true) record but in practice there can be zero or more records even there ;)
You could also consider using the table name als the id field. In case of employee, the identifying field would be 'employee', so in other tables you would end up with something like 'benefit.employee'.
We don't use this convention ourself btw
