http://www.perlmonks.org?node_id=129778


in reply to Frivolous function names

So which is which? To me, if I summon someone, then I'm not sure whether they will come in response to my summons or not. But if I "get" them, then, well, I must have got them. So my first reaction is that the "get" is more forceful than "summon" and so would be the one that would "do whatever it had to" to get me what I demanded.

Further, I would never use "summon" when requesting something that might not be available. I "summon" something specific that I assume already exists: "Summon Dr. Smith". While I might use "get" to request something that may or may not be handy: "Get a doctor".

But elsewhere in this thread it appears that you have chosen just the opposite arrangement, apparently considering "summon" as in "to summon a daemon".

So, no, I don't consider that a good choice of names.

I'm even a bit surprised that you use "get" for looking up things that might not be there. I'd expect a "get" routine to only fail as an exception and a "find" or "lookup" routine to note "none such to be found" as an unexceptional failure result.

But if the point is to note that creating an item first requires that you check if it already exists, then I'd certainly put something like "create", "make", or "new" in the function name. Though using underscore_laden_names certainly motivates one to keep the number of words in an identifier to an absolute minimum since get_or_create_foo() is a pain to type. But I consider that a reason to avoid using underscore_laden_names.

Just yesterday I was discussing how difficult it can be to come up with good names and how easily (and a bit surprisingly) a bad name can lead to bugs. We were trying to name the class the encapsulates what an operation is waiting for (it can be an event, a timeout, both, or "nothing" as in "I'm ready now" or "nothing" as in "I don't yet know what I want to wait for", etc.). Most of the names sucked because they used terms that had attracted specific computer science meanings like "event", "trigger", "condition", and "signal" or that could be read as more than one part of speech like "wake" (is "WakeEvent" an event that wakes something up or a request to wake up an event?).

I eventually proposed "WhenToWakeUp" half jokingly. But, although it isn't the type of thing you think of when asked to come up with a noun (which class names must be according to our coding standard), it actually is a noun phrase and seems to describe the purpose of the class very concisely and unambiguously (we actually implemented it as a nested class so its full name is ...WaitingOperation::WhenToWakeUp), though I'm probably missing some problematic interpretation. (:

So there is an example of a bit of a whimsical name.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re (tilly) 2: Frivolous function names
by tilly (Archbishop) on Dec 06, 2001 at 18:27 UTC
    I think that expectations are strongly shaped by what we have around us.

    I have dealt with a lot of code with get methods that issue no complaint if you try to get what isn't there. None of it will autocreate just to succeed. So for me a get method that creates is very surprising.

    As for which is stronger, well the fantasy connection is one reason I think in terms of summoning being stronger. The next image that comes to mind is comparing getting a person, when that person can just say, "Sorry, I'm busy" versus issuing a legal summons where if you don't show up, you can go to jail.

    But still, if your expectations are opposite, the name is unclear. I should therefore change it... *sigh*

    As for your class, I would have named it something like WaitingFor (or with the captitalization I use, waiting_for). But then again naming things is my least favorite part of programming...

      Unfortunately WaitingFor is not a noun and so violates our coding standard for class names (which would probably lead to confusion even if we told the coding standards to take a flying leap in this case). We came up with other similar names that seemed clear but weren't nouns as well.

      For some reason, phrases were bouncing around in my head today:

      "We always summon our man!"

      Captain: "What are we going to do about this criminal?"
      Officer 1: "I'm going to summon him!"
      Officer 2: "I'm going to get him!"

      "I summoned the daemon."
      "Did you get him?"
      "No, it didn't work"

      Although "summon" denotes exercising authority, it also denotes letting the person that you seek decide whether or not to respond to that authority. It isn't an action, it is a request. Summon might even denote an asynchronous request to me where you issue the summons and then come back later to see whether anything responded.

      And I'm used to "get methods" being accessor methods for object attributes which are things you usually don't expect to fail.

      On the other hand, a "find" method implicitly means "try to find" for some reason. I guess because "to find" implies a non-trivial amount of work is involved and so it is unreasonable to rule out failure.

      Yeah, naming is one of the least rewarding parts of programming, while it can be surprisingly tricky, time-consuming, and important.

              - tye (but my friends call me "Tye")