• Post Reply Bookmark Topic Watch Topic
  • New Topic

Naming convention?  RSS feed

 
Barry Burd
Author
Ranch Hand
Posts: 133
10
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a standard naming convention for a method of the following kind...
Not a setter/getter method (that is, doesn't provide public access to an otherwise private member of the class)
Not a finder method in the EJB sense
Does calculate a value and return that value, or otherwise fetches a value from some other source and returns it to the caller.
For instance, I'm creating a method
obtainDate
that, when called, makes a call to an NTP server and obtains the date, and then returns that date to the calling code ...
calling code --calls---> obtainDate ---calls---> NTP server
<-returns-- <-returns--
Is there something I should be naming this method other than "obtainDate"?
Thanks.
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not that I know of.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nor I. As long as you don't call it getDate() since that sounds like a simple bean method. I might consider things like:
lookupDate()
currentDate()
dateFromNTPServer()
Of course two out of three of these are already ignoring the common convention of starting a method name with a verb, so maybe you don't want my input here. But plenty of Sun's method names ignore this one too, so it's a matter of taste.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One could argue that getDate() is ideal precisely because it sounds like any other getter or setter and completely hides the fact that you're doing some gymnastics to actually obtain the date. Starting down a road of a dozen significant synonyms for "get" (compute, obtain, find, retrieve, lookup, pleasePassThe, etc.) sounds scary.
I guess I haven't used frameworks that assumed bean standards ... when would a get method that does not correspond to a member variable cause trouble?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True. When I suggested dateFromNTPServer() I was thinking more of the sort of name I might give a private method, to decribe what it's doing. But you're right that the NTP server probably isn't the sort of thing we want to mention in the public API. As for why not getDate() - well I suppose it isn't that unthinkable. But the reason I don't like it is that when I see a getter I look to see if there's also a setter; if I don't see a setter I figure it's supposed to be an immutable field. Well hopefully I'll read the API more carefully since that assumption isn't necessarily justified, but that's what I'd expect first, absent other info. "Get" makes me think of an instance field that shouldn't change unless "set" is called. Maybe that's just me. But if I've got some data that changes in response to something external, I'd try to give it a name that makes that clear - or at least, doesn't just say "get".
On balance, I like currentDate() (or lookupCurrentDate() if we must have a verb) best. Similar to currentTimeMillis(). Don't reveal how exactly it's obtained, but do say what it means, and don't use get. That's my vote anyway.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting points. I love this place!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!