8

I have this personal rule to start all function/method names with a verb. My verb of choice for functions or methods that get a value based on some data structure or object is get. I'm wondering if that's a good idea.

The good thing about get is that it doesn't really say anything about how that value is being retrieved, just get it. Something like calculate (apart from being awfully long) may be too much information.

This applies to both functions and methods, i.e.:

float get_magnitude(Vector2d vector)
{
    return sqrt(pow(vector.x, 2), pow(vector.y, 2));
}

or

float Vector2d::get_magnitude() const
{
    return sqrt(pow(x, 2), pow(y, 2));
}

On the other hand, I sometimes end up with getter methods for read-only properties. It may make sense to use a more meaningful verb for anything that doesn't just return some property, and may not run in linear time.

Is there a case to be made for either approach or is it just a matter of taste?

futlib
  • 2,107
  • 3
  • 21
  • 26
  • 1
    One wonders if you were in charge of the standard library, might you rename `sin()`? Perhaps `get_sin()`, or `calculate_sin()`? Verbs are great for naming functions that *perform actions* because verbs are *action words*, but... mathematically pure functions such as `sin()` and `magnitude()` do not perform actions (at least, not at the usual level of abstraction), therefore they should not be named with verbs. – Dietrich Epp May 15 '13 at 10:26
  • @DietrichEpp That has me thinking, but I believe I can argue sin() away: _sine_ is the name of an actual mathematical function, while _magnitude_ describes the result of some computation, just like _square root_. Would I call the _sqrt_ function _get_square_root_? I think so. – futlib May 15 '13 at 11:32
  • 1
    "Square root" and "magnitude" are also ordinary mathematical functions, like "sin". Why do you say they are different? Maybe instead of `1 + 2` we should use `calculate_sum(1, 2)`, because it is more consistent? – Dietrich Epp May 15 '13 at 11:54
  • @DietrichEpp I agree, it's not such a clear distinction. We do say "The sine of x" or more generally "f of x", so function/result is synonymous. In that sense, we might think of sine as a property of a number x though. Aren't all functions that get/calculate a value from some input structure without changing it mathematically pure? – futlib May 15 '13 at 12:24
  • Yes, that is a common definition of a pure function. Most programs will mix pure and impure functions. I don't like tacking `get` or `compute` onto pure function names because it's just noise, I can figure out that the function name gets or computes its result if its name is a noun. And the distinction between `get` and `compute` is really an implementation detail, I wouldn't want to make it part of the interface. – Dietrich Epp May 15 '13 at 21:41
  • 2
    The presence/absence of a verb also communicates information about the method, so we can use `matrix.invert()` for a method that modifies the matrix, and `matrix.inverse()` for a `const` method that returns a new matrix. This way, pure functions and pure methods don't get penalized with unnecessarily long names. – Dietrich Epp May 15 '13 at 21:43
  • @DietrichEpp That's a good point in favour of not prefixing anything with calculate. I'm not entirely sure about dropping all the get's, but you have a point, there's not really a need for it. – futlib May 16 '13 at 09:29
  • @DietrichEpp I'm following your advice after all by now, it's not really helpful to have a verb in the name of pure functions. All the gets are gone now, with the exception of actual accessors (of which I only have few). – futlib May 23 '13 at 04:15

6 Answers6

12

Consistency in naming functions is good, but you can also overdo it.

If every function that returns a value is called getSomething, you are probably overdoing it. My advise would be to reserve the get prefix for things that are conceptually properties of the object that the function works on, even if the value is not explicitly stored in the object (like the get_magnitude in your example).

If returning a value is not the most important aspect of the function, but merely a side-effect of the function's true purpose or design, then I would name the function after what it does. For example, there is no way that I would give C's fopen function a get prefix, even though the function returns an important value (a handle to the file just opened).

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
  • I'm not prefixing "every function that returns a value" with get, that would defeat the purpose. I'm prefixing "every function whose sole purpose it is to retrieve a value or a set of values from some data structure or object". Nor would I prefix fopen with get, I'd call it "open_file" and I'd have my verb :) – futlib May 15 '13 at 09:35
  • 4
    That said, "Reserve the get prefix for things that are conceptually properties of the object [...], even if the value is not explicitly stored in the object" sounds good to me. – futlib May 15 '13 at 09:41
  • @futlib: I extrapolated your question in the "every function" part, just in case someone would think it a good idea. I did not mean to imply that you were foolish enough to do it. – Bart van Ingen Schenau May 15 '13 at 09:53
  • It just reads better if method names start with a verb, and, human readability is the only issue here. The program will run just as well with functions/methods named "m1", "m2" "m3" .... – James Anderson May 16 '13 at 01:48
  • @JamesAnderson: Sure. It is common and good practice to use verb-phrases as function/method names. But that does not mean all functions returning a value should use the verb `get`. If I had to rename `fopen`, I would rather go for `open_file` than for `get_file_handle`. – Bart van Ingen Schenau May 16 '13 at 08:42
7

Consistent clear naming is good, so "get_thingy()" is good, but I don't see that read only versus mutable makes any difference here as you are only "reading" the value.

I like "of" as a suffix id you need to pass a parameter as in "get_square_of(3)", and, if you know there is a lot more involved than a simple retrieval or calculation then maybe another verb like "obtain" can be used to indicate this as in "obtain_meaning_of_life()", also some people favor "retrieve_" to indicate the method involves some sort of I/O or external interaction.

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • What about my example? The magnitude of a vector is in some sense one of its properties, but it's also a slightly expensive calculation, with the sqrt. – futlib May 15 '13 at 09:37
  • 2
    @futlib: A different name can't prevent something from becoming a performance bottleneck. The fact that you need a computation is entirely based on an internal implementation detail. Or do you propose to change the method name's prefixes when you change a `Vector`'s implementation from Cartesian to polar coordinates? – Bart van Ingen Schenau May 15 '13 at 09:46
  • @futlib -- for a modern computer your maginitude() method doesn't really count as "a lot" -- something that takes more than a tenth of a second or thereabouts. – James Anderson May 16 '13 at 01:46
1

Hmmm ... Well it's almost always a personal preference isn't it. In general, I think that naming conventions should be such that not only I understand what's going on in my source code, but also so does whoever else comes across my code. Also, I tend to be a minimalist in code documentation; unless I am doing something very tricky, my code should be smart enough to explain itself to me even if I see it 3 years from when I wrote it in a drunken stupor. So consistency across your projects, for internal sanity is important too.

For instance, when I use C on *nix systems, I invariably use 0 as success and negative numbers for flagging failures; with the exception on I/O functions where return is size_t; then positive number is amount of I/O; 0 is a halt on I/0 and (size_t)-1 is a fault with errno set to a system error; this is consistent with C library behavior on the systems so I know that everyone will understand what is going on.

When I used to write programs under Win32 using C the convention of Win32 was a bit different and I followed that convention. There, the names use camelCase in C (which is annoying to me but I follow it) and use Hungarian notation (which is even MORE annoying) but I stick to using that.

However if I were to write equivalent code in C++ I would switch the way I report errors. Throwing exceptions or using boolean return values for simpler methods.

If I am in kernel programming mode, then I use the conventions used by kernel developers;

I figure that I do NOT want to spend time explaining my code to others (which includes me 3 - 5 years from now because I'd have changed) so I use the dialect that they'd understand on their own rather than me having to explain MY logic to them (they really aren't that smart, and I am getting stupider by the year).

I think whatever you use, keep it consistent along some logic path that can survive across languages, across systems and your growth between now and 10 years from now.

Ahmed Masud
  • 285
  • 2
  • 7
0

For methods aimed at retrieving a value, some people just omit the verb, considering that this is just an access to a property:

float Celsius() { return self.celsius; }

float Fahrenheit() { return self.celsius * 9.0/5.0 + 32.0; }
mouviciel
  • 15,473
  • 1
  • 37
  • 64
  • -1 We know some people do this, but you are not making a case. Is this a good idea? Why? Particularly, I don't think it is, because the resulting names are confusing. Does "Celsius" get the quantity in Celsius, set it, compute it...? – CesarGon May 15 '13 at 07:53
  • @CesarGon - For setting, the name is `set_celsius`. – mouviciel May 15 '13 at 08:11
  • See? That's confusing. ;-) If setter is "set", you want getter to be "get" for the sake of consistency. – CesarGon May 15 '13 at 13:43
  • 1
    @CesarGon - I have a different opinion. If I want to set the time on my watch I have to *act* on the watch. If I want to know what time it is, I just have to look at it: No action on the object, thus no verb, is involved. – mouviciel May 15 '13 at 14:12
  • Yes, I understand that; you made it clear in your answer and your comments. I am just stating my views, which are different, and justifying why. All good. – CesarGon May 15 '13 at 16:07
0

Depending on the language you work in, the getThingy or get_thingy might be superfluous.

Consider a typical C++/Java/C# class with a bunch of getters and setters that are just accessors to private members, which is something that for better or worse, a lot of see every day.

What's the difference between getCustomerId() and customerId()? I would argue that there's not much difference at all, because we know full well that both are just retrieving a member. But the latter has a number of pragmatic advantages:

  • getCustomerId() convention will force you type get many times a day.
  • if you have autocomplete, it won't meaningfully kick in until you type getC*, while in the latter case it will kick in after the first letter. My fingers already hurt, and you're forcing me to keep reaching for the shift key all day long (or the underscore for get_thingy)? Not cool.
  • You lose the meaningful 'get'. What I mean is, if my convention for the accessor was customerId() and all of a sudden I'd see a function called getCusomterId() I would understand that perhaps it does more, such as going to database maybe, or iteratres some list? In absence of get people are forced to use verbs that are almost synonyms, and because they are synonyms this creates confusion.

I'd like to close with the following: we should always use the minimum amount of anything required to get us to where we want to be. Efficiency is the key to doing things intelligently. The rule of 'always have a verb in a function' is one of those mantras that just doesn't pass that test imho. Personally, I blame Eclipse's auto-generating of setters and getters for the status quo.

People, please drop superfluous get s from your code. They don't actually mean anything.

MrFox
  • 3,398
  • 2
  • 19
  • 23
  • i appreciate your response. but for me: customerId() is not clear what it does. does it create a new customer id? validate it? return it? sometimes clarity of method is worth a few extra characters. – cartalot May 15 '13 at 19:37
  • 1
    @cartalot I suppose for me getCustomerId() is equally unclear as whether it creates it, returns it, fetches it from a list etc. – MrFox May 16 '13 at 16:41
  • Thanks that is helpful to know. I would respond that you can't "get" something that does not exist yet. I have been using 'insert' like insertCustomerId() for the initial creation. The list example is good - and i'm not sure. My idea with "get" is that its implying there is a strong boundary, and that there is a potential for failure. If you already have a list of customers in an array, then the method name would probably be more specific to what is going to happen with the customerId... – cartalot May 17 '13 at 18:38
0

This is such a great question, i am dealing with similar issues right now! At this point i am trying to learn clean code techniques for naming - methods should be named well enough to make comments unnecessary.

However there is more then one great way to name something. So now i am looking at a working application with a bunch of classes and clear names. But they aren't completely consistent and that would make the app more clear.

I've been using get alot recently. For me its only 3 letters, it looks good in camel case, and it makes it crystal clear what is happening. there is no ambiguity with getProductBy($id). Also for me with get - there is an important hint that we might not get the result back. There might be an error with the database, etc etc etc.

So getProductBy($id) also issues a warning to the application flow - we are going to try and get a Product by id, AND it might fail so there has to be error control for whatever happens next.

cartalot
  • 225
  • 1
  • 5