About Dan Wilson
Dan Wilson
Dan Wilson
Model-Glue:Gesture for Fun and Profit
Watch Video
Presentation Files
DataCurl LLC, My Company
2010 Speaking Engagements
Video Interviews
DZone Articles
The Art Of Method Names
Posted By : Dan Wilson
May 21, 2009 1:12 AM
I write from time to time on code quality and structure because it is a topic of interest to me. Clean code and well named logical structures, methods and objects really pay off during the infinitely long Support And Maintenance phase of software development.
Some could accuse me of having too many opinions on the topic, and I'd guess they could be on to something. Heck, I'll probably disagree with something I've said today, tomorrow, just because I'm always refining and learning.
While some of what I think/advocate/do is opinions, and could be subjective, I'd like to share some code I found on a project today and talk about the importance of method names.
A method should describe it's intent or behavior at the level of where it is inside the program. For example, a method named load() might be sufficiently descriptive to represent the behavior and be flexible enough to withstand a refactor or two. In other places in the program, perhaps the right method name is loadShippedOrders() since there will always be the concept of a shipped order in our proverbial system.
You get the point, right? There is a wide range of OK-ness for method names, with behavioral descriptiveness and refactorability as being two made up words that really judge the method name quality.
I found code today that really flies in the face of any of these principles. The names of these methods do not in any way describe any behavior of any system I've ever written, nor will probably be lucky enough to write.
method bodies removed to protect client interests
Be the Judge Yourself:
2 <cffunction name="phoneHome" output="yes">
3 </cffunction>
4
5 <cffunction name="createDir">
6 </cffunction>
7
8 <cffunction name="createDirImpl">
9 </cffunction>
10
11 <cffunction name="beamMeUp">
12 </cffunction>
13
14 <cffunction name="energize">
15 </cffunction>
16
17 <cffunction name="setPhaserToKill">
18 </cffunction>
19</cfcomponent>
Before you ask, this code was found in a production eCommerce system that is currently running that has nothing to do with Phasers, Energization nor beaming anything to any location.
There are no comments for this entry.
Add Comment
Subscribe to Comments
Clearly someone was bored that day.
I can't agree with you more about the importance of naming functions/methods/classes appropriately... what a crazy example. :)
Ok, so "createDir" makes sense, but WTF is "createDirImpl"? It's not even internally consistent... as senocular points out it's a funky mix of ET, boring, and Star Trek!?!?
Somebody was on a seriously weird flavor of crack when they wrote that! I'm guilty of drunken-coding periodically, but I don't think I've ever written anything that bizarre. :)
you can describe methods with displayname and hints attributes of cffunction tags, i think it is important a good naming of variables too
Can you please share the code for the beamMeUp function? That would be a nice snippet to keep on hand.
"CreateDir" makes sense? Maybe if it was for a utility component working with files, But what if it's not for creating a directory? It could be create directions. Or what if dir is an acronym for something else relating to the application? I'm a big believer in just typing the whole name out. It makes it crystal clear for others reading the code. And it's easier to type the entire world than trying to remember the abbreviation style for that particular application (ever notice how each one seems to have it's own lil twists on abbreviations?).
I agree with you James. I am a sub-fan of abbreviations for the same reason as you. There are too many deviations and personal twists and I am all about writing clear, legible, descriptive code.
DW
That takes me back to high school when we would sneak on to each others accounts in programming class and search/replace our classmates function names with the names of nascar sponsors and breakfast cereal brands. I miss the good 'ol days.
This is insanity. I thought you were just making that up as an funny example of something that one might see, not something you actually found in an actual application. For what it's worth, I completely agree on the topic and we try to be very clear these days with out method naming. This came about after some tough times reading through our own legacy code and dealing with a lot of single letter variable names (aid,oid,etc).
Reminds me of a GCHQ project I once saw part of (GCHQ = British version of NSA)... in order to "protect" what the code really did, all the objects were named for fruits instead of what they actually modeled. Boy, did that make for some weird code...
This reminds me of some code a classmate in college wrote for which he had many points deducted. The code was to store a serial number in a hash table structure. He named the variable for the serial number "bran" (think cereal) and the variable for the hash table "spud" (think potato). I am glad he had points taken off.
Maybe SetPhaserToKill is a bad attempt at a destructor?
Suscribe
Follow Us
Contact
I agree. Everyone knows ET never used phasers. COME ON!