Wednesday, March 24, 2010

What’s in a Name?

I was asked a question the other day about a table layout:

My first table is tbl_Department with the columns as 'dept_id-auto generated', 'dept_name'.

My second table is tbl_Employee with the columns as 'emp_id-auto generated', 'emp_name', 'deptname'.

It is completely un-necessary to prefix database tables with tbl. It is an archaic practice that should be abandoned, outlawed, and punishable by exile from the development community.

Notice the field names. They were kind enough to name the tables Department and Employee, but then decided to abbreviate the table name as part of the field name (dept_id). Most developers are intelligent enough to discern that a field call ID in a table called Department is probably the unique value assigned to a department and used to identify it among all of the other departments.

Now don’t get me wrong. I am all for writing code that uses naming conventions that help to elucidate its intent and meaning. And, I will admit, my interfaces begin with “I”, but that does not mean adorning variables, methods, functions, classes, and tables with needless prefixes and/or suffixes is, as a practice, a good thing. It creates noise and rather than clarity.

No comments:

Post a Comment