CleanCode logo
NAVIGATION: first page in sectionprevious pageup one levelnext pagefinal page in section

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.

Instead of:
		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]... }
Valid XHTML 1.0!Valid CSS!Get CleanCode at Fast, secure and Free Open Source software downloads
Copyright © 2001-2013 Michael Sorens • Contact usPrivacy Policy
Usage governed by Mozilla Public License 1.1 and CleanCode Courtesy License
CleanCode -- The Website for Clean DesignRevised 2013.06.30