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).

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.

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.

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; }

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.

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.