SEARCH:
NAVIGATION:
Guideline NM3: Add clarity with consistent naming
Guideline NM2 discussed naming conventions; here we discuss actual naming,
the distinction being that the former deals with models, the latter with concrete instances.
Let's say you have a module which provides a variety of library functions involving calendar date manipulation.
Several of these functions use a string parameter containing a date in the format yyyy-mm-dd.
A sloppy coder might name this parameter dateString in one function,
date in another, d in yet another.
But what good does that do? There are no advantages to doing that, only drawbacks.
If, for example, our sloppy coder does not document these functions (not surprising),
then anyone else reading the code--or even the sloppy coder reading the code the following month--could not necessarily
tell that dateString and date refer to the same kind of object.
Our example shows a matched pair of accessor functions--a getter and a setter--to illustrate the right way
and the wrong way.
String getItem(String name) { ...stuff[name]... }
void setItem(String ref, int val) { ...stuff[ref]... }
String getItem(String name) { ...stuff[name]... }
void setItem(String name, int val) { ...stuff[name]... }
