Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Frivolous function names

by tilly (Archbishop)
on Dec 05, 2001 at 23:55 UTC ( [id://129726] : perlmeditation . print w/replies, xml ) Need Help??

Just today I ran across the need to have a pair of functions, one of which would try to fetch something and return undef if it couldn't, the other of which would try to do the fetch, and would create the thing if it wasn't there. After some playing around in chatter I settled on a suggestion from Petruchio to use the naming style get_foo() and summon_foo(). Anyways the names work, are fairly short, and are reasonably descriptive. But they got me thinking..what other whimsical sounding names have people here wound up using?

Replies are listed 'Best First'.
(Ovid) Re: Frivolous function names
by Ovid (Cardinal) on Dec 06, 2001 at 00:41 UTC

    Please ... this is just between us. You'll keep quiet, right?

    I actually have the following in some production code:

    my $yea_verily_I_say_unto_thee_that_the_number_of_the_tr_tag_shall = $ +tr_start;

    Someday, someone is going to either laugh their @$$ off or hunt me down and kill me :)


    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

(Ovid - more frivolity) Re: Frivolous function names
by Ovid (Cardinal) on Dec 06, 2001 at 02:03 UTC

    If you want to see a fair amount of frivolity, check out some of the source code from the CPAN. Here's some snippets from the tests of Test::Simple:

    use_ok('Hooble::mooble::yooble'); require_ok('ALL::YOUR::BASE::ARE::BELONG::TO::US::wibble');

    My personal favorite:

    SKIP: { skip $Why, 2 unless Pigs->can('fly'); my $pig = Pigs->new; $pig->takeoff; ok( $pig->altitude > 0, 'Pig is airborne' ); ok( $pig->airspeed > 0, ' and moving' ); }


    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Re: Frivolous function names
by tadman (Prior) on Dec 06, 2001 at 03:42 UTC
    Whimsy, in the kernel?
    while (is_computer_on() && !is_computer_on_fire()) { do_stuff(); }
    From BeOS.

    No, really.

    As for semantics, I like to keep function names paired, such as Get/Set, Load/Save, Begin/End, Start/Finish and so forth, and try not to mix them.

    The use of something like fetch_record() implies that it will try and retrieve it if possible, unless there is no record to fetch. However, get_record() may imply that it gets a record, even creating a new one of required. That get_record() might come back empty handed could be a bit of a surprise. It's like, "Hey! I asked for a record, where is it?"
      IIRC, some of the old 68xx processors had undefined opcodes. Most of these were effectively NOP, but at least one sent the processor into a mad series of loops,and could be stopped only by powering the machine down. I always heard it called "HCF", standing for "Halt and Catch Fire". I never saw it for myself, but it had its fifteen minutes of fame.


      John Davies
Re: Frivolous function names
by dws (Chancellor) on Dec 06, 2001 at 00:35 UTC
    Just today I ran across the need to have a pair of functions, one of which would try to fetch something and return undef if it couldn't, the other of which would try to do the fetch, and would create the thing if it wasn't there.

    On the theory that names are most useful from the client's perspective, and not the service's, how do these differ? If the client doesn't need to know whether the Foo it is requesting from the service is potentially created on-the-fly, then getFoo() is a perfectly reasonable name. To use a name like getOrCreateFoo() can reveal to the client aspects of the service that are none of the client's business.

    In cases where a client does legitimately need to make a distinction between whether the service already has a Foo, naming gets problematic. Assuming that the service has getFoo() and newFoo() functions, then getOrCreateFoo() is really behavior that a client could synthesize, but which the service is absorbing as a convenience to its clients. In these cases, I've tended toward a scheme of findFoo() and getFoo(), where the former means "give me one if you've got it" and the latter means "give me one". In both cases, though, a client needs to check for none. Even in the case where a new object is going to be created on the fly, things can happen, and the burden of verifying is always on the client.

    The problem of a service absorbing convenience functions into its API is a tricky one. On one hand it prevents duplication of code in clients, while on the other hand it introduces bloat into the API.

      The client did need to know.

      There is a sharp distinction between attempting to access things and trying to create/overwrite/modify them. I have a need to expose that distinction.

      As for the find/get distinction, I thought about that but decided against it because where get appears elsewhere in this codebase it generally means "fetch" and doesn't autovivify. If you and those around are consistent about it, find/get is a doable proposition, but I don't want to deal with someone in 3 months saying, "Why did it just create that?" and having to say, "Well, didn't you know to use find instead, unlike how it works everywhere else?"

      I figure that people won't accidentally summon, and if they do try summoning, they won't be terribly shocked if summoning does something rather different than getting does. (Nor am I terribly shocked at the idea that a summoned thing could have been conjured up out of nothing.)

Re: Frivolous function names
by buckaduck (Chaplain) on Dec 06, 2001 at 01:21 UTC
    I used to have a summer intern who was very talented, except that nearly every program she wrote was named after one of her cats. Most of the variables and function names were things like "meow" and "purr". Every now and then when I'm debugging her code, I call her on the phone and let out a primal scream.


(tye)Re: Frivolous function names
by tye (Sage) on Dec 06, 2001 at 02:30 UTC

    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")
      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")
Re: Frivolous function names
by dragonchild (Archbishop) on Dec 06, 2001 at 00:25 UTC
    Firstly, I hope you wrote summon_foo() as a wrapper to get_foo() and create_foo(). :-)

    Personally, I like using abcd and efgh as my scratchpad scripts. Of course, loving golf as much as I do, I almost always have a window open to abcd in some directory where I'm golf'ing. :-)

    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Close. There is no create_foo. Just summon_foo. In my case there should not be duplicate things in existence, and hence it makes no sense to create unless you first try to get, and furthermore if I some day wanted to add locking logic, this would give me a clear place to do that.
Re: Frivolous function names
by perrin (Chancellor) on Dec 06, 2001 at 02:14 UTC
    It always cracks me up when Java programmers talk about calling the "passivate" method on EJBs. In my own code, I once did things like name a boolean $jeff_is_a_swell_guy, which was false until Jeff fixed the bug that I was working around. But for function names, everyone knows there's no need to have more than one: do_it()
Re: Frivolous function names
by chromatic (Archbishop) on Dec 06, 2001 at 07:11 UTC
    I thought you were talking about Carp for a moment. That's the most useful (Perl) example that comes to mind. The XP folks would say that the metaphor you use to determine your general architecture should suggest good class and function names.

    If I were summoning things with fair regularity, I'd name it somewhat differently. Then again, as Ovid points out, tests are a good place to do that sort of thing.

Re: Frivolous function names
by demerphq (Chancellor) on Dec 06, 2001 at 18:22 UTC
    Personally I probably wouldn't create two different methods for this, as other posters have observed practically any names you come up with could be misunderstood or end up being so long as to be unweildy. Instead I would create one sub that took a parameter to indicate if it should autovivyfy or not, something like
    use constant CREATE_IF_NOT_EXIST=>1; use constant NO_CREATE=>0; sub get_foo { my $flag=shift || 0; #..... } my $obj=get_foo(CREATE_IF_NOT_EXIST); my $obj_or_undef=get_foo(NO_CREATE);
    IMO this makes for cleaner and easier to document and remember code. You could even make it die if the sub does not get a parameter, forcing the client to always call it with an appropriate param.

    Yves / DeMerphq
    This space for rent.

      Ironic. While offering me advice on how to avoid having any ambiguous names, you have hit on a horribly ambiguous name that I would never leave in code.

      One of the most common programming errors - and a hard one to see - is to reverse the meaning of a flag. For that reason I consider any flag horribly misnamed unless the name is a yes/no question which its value is an answer to. For instance your flag might be appropriately named $will_create. Do that and you will stop making that particular mistake again.

        I admit I didnt take a lot of time to write my code snippet as my point was to avoid naming problems and use a flag. The choice of name for the flag variable would be the authors call. Although on second thought I wouldnt use $will_create but probably $create_on_demand

        Anyway, point well taken though, in future Ill put more thought into variable names in my snippets...


        On second thought there is a point here actually. You were talking about externally available names, whereas $flag while poorly named is internal and thus less of an issue. This isnt to say that $flag was a good name, it is not. But there is more room for error in internal use code than external use code, especially if said variables/code are properly scoped. </bad_excuse>

        Yves / DeMerphq
        This space for rent.

Re: Frivolous function names
by boo_radley (Parson) on Dec 10, 2001 at 20:57 UTC
    Not whimsical, but frivolous.
    Medium sized CGI application. No templating. Each page generated by a sub named "Pagen". Not wholly organized, but grown in a very organic matter; "we need a new verification step to the 'buy a widget' page!", ok, that page is Page4, next available is 72, there we go. Later on, the developer left... and chaos ensued.
    <screed> I'll take this moment to point out that we can hone our skills to razor sharpness, people tend to sink to the level that they're managed at -- people will not do what they can get away with not doing, as was the case in the example above.
    It was remarkably easy for some to bluff their ways out of task I consider critical as a programmer all because the manager of the project had no technical background. Because of this, I think it's necessary for programmers to realize they have a stake in the management structure around them. </screed>
Re: Frivolous function names
by Molt (Chaplain) on May 16, 2005 at 16:40 UTC
    I'll admit it's a set of script names rather than function names, but at the last place I worked we did end up with two production batch systems called and
Re: Frivolous function names
by qbxk (Friar) on Dec 30, 2005 at 13:38 UTC
    i needed a die/croak etc, that wrote the message out to like 16 places if it got there (don't ask why) - this function was:

    sub freakout($)