How to name a variable when the word is both a noun and a verb?

One developer is not a fan of double meanings.

This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 90+ Q&A sites.

GlenH7 has a word problem. His team is using a word—"charge"—that can be either a verb or a noun. "And in some cases when we're discussing the application, it will be used both ways in the same sentence," he tells us. This is confusing, considering it's conventional to use nouns for variables and verbs for functions. What should GlenH7 do, and how can programmers avoid noun/verb naming problems in the future?

Use more letters

In similar situations I try to find synonyms. In this case I would use "recharge" for the verb. The "re-" is slightly redundant, but the meaning is clear. Using the simple "charge" for the remaining charge in the battery is ambiguous because it doesn't specify any physical units. I would prefer "availableAmpHours," "hoursUntilRecharge," or something similar. The units will depend on whatever is convenient for the application.

My personal preference is to use verbs only for functions that change state. I use nouns for non-mutating functions. I suppose it depends on your point of view. At the machine level, non-mutating functions do something, but at the model level, they don't.

Think about functionality

Just throwing this out there, but maybe the solution for this instance of naming ambiguity is to remove that functionality from the battery entirely. I've never seen a self charging battery and it would make more sense to me to have a BatteryCharger class. This would help keep your concerns more decoupled and make the action more explicit.

battery.Charge(50) vs batteryCharger.Charge(battery, 50)

To me, the second form is much more understandable and keeps all your "Charging" code in one place rather than sprinkling it throughout all your battery classes.

Follow these rules

Avoid double meanings

You have deliberately selected a word that has more then one meaning, and that first decision is the problem. There are a ton of words that are problematic for programmers. Another example would be phone. You can phone someone, or you could have a phone in your pocket.

Use getters and setters

The standard naming for most objects is the getters/settings methods for properties:

Battery.Charge // would be a propertyBattery.setCharge(value) // would set the propertyBattery.getCharge() // would get the property

Properties Are States Not Nouns

I think you are mistaken by classifying object properties as nouns, and variables could also be thought of states. They are states relevant to the local scope of their existence.

You could describe the value that they hold as a noun, but I'm not sure that is true in all cases.

In OOP terminology object properties describe the state of that object. In your case the Battery is an object, and its Charge is a state. So that would be a property of the object, but this depends on the context of how it's used.

If you need to be able to Charge the battery, and also know what its current Charge is, then you have a problem.

Using Scope To Enforce Context

Context is what will clarify which meaning of a word you intend a method or property to convey. Scope is setting the accessibility of a property/method from outside the object.

Batter._charge // a hidden private propertyBattery.setCharge(value) // would set the private propertyBattery.getCharge() // would get the private propertyBattery.Charge() // would perform the Charge action

Methods Are Verbs

You can describe the method of an object as a verb, but the word action is better suited. In OOP terminology you perform actions upon objects using their methods. It's bad form to modify an object's property from outside the object. It's preferred to call a method that performs the actions required that causes its state to change.

The word Charge is a verb, but it's also a noun. When used to call the method of an action it becomes clear that the verb is being used Battery.Charge(....).

But context is very important. While the word Charge() is a verb it's not as meaningful as startCharging().

38 Reader Comments

As many words as there are in as many languages as we have, it can't be this complicated to just find a more descriptive word. Or in this case, use a different tense. Or both: ChargedLevel, ChargedState, ChargedPercentage.

In the case of batteries, it's actually the output voltage that indicates the level of charge in the battery. So logically, you would set a variable to monitor the voltage of the battery rather than use the word charge, which is more of a colloquial term.

SMH. Languages like English are great for developing sentences quickly, but they're terrible for maintainability, and this demonstrates why. If it weren't for speaker lock-in, way more people would use a statically typed language instead, like... Uhm...

My observation, native English speaker, is that variable naming scheming is poorly thought out not enforced properly. The question is what does "charge" refer to? The amount of charge (or state) of the battery or the act of charging the battery. In physics and electrochemistry "charge" is normally understood as the state of the battery (or capacitor) while "charging" refers to the act of adding charge to the battery (or capacitor).

Another issue are the terms "charge" and "charging" to vague for your code? This depends on the complexity of the code itself and what you need to monitor and display to the users.

Remember Calvin & Hobbes - verbing weirds language! In the event of ambiguity, use verb phrases to visually flag verbs: doCharge(), doFlag(),etc; versus noun phrases for nouns: myCharge, myFlag etc. If you are using a language which distinguishes between properties and methods (like Objective-C) you can relax a little, since [roadworker flag] is much different than the boolean roadworker.flag. In Java, you're sort of on your own. You can use get/set bean conventions, if you're in a bean type of situation (like Spring) but otherwise you have to use your own conventions. (And today's noun could easily be tomorrow's verb - like Calvin said, "access" was once a noun.)

The English language is an incredibly malleable language, possibly the greatest of all in this respect. Use it to your advantage. The amount of puns you can do in English is unparalleled and we all know that love of puns correlates with IQ so knock yourself out and have fun. For example

The English language is an incredibly malleable language, possibly the greatest of all in this respect. Use it to your advantage. The amount of puns you can do in English is unparalleled and we all know that love of puns correlates with IQ so knock yourself out and have fun. For example

You can almost invariably add a modifier if it's really an issue. "theCharge" or "doCharge" are perfectly clear English, and quite succinct. I like "aCharge" if I have a member of a set of charges.

Just don't use Hungarian Notation. The point is so that people don't need to look up what a token means to use it, right? Besides the fact that that's a terrible idea, they *should* be reading your docs, if they're not going to bother looking it up, they won't bother to look up the correct Hungarian Notation! That's even assuming they knew where your local standard was published.

Your artificial language of choice already has syntactic structures to figure out what different tokens mean, and your natural language of choice is far superior to some coding scheme you cooked up while high, so there's really no need for Hungarian notation.

This approach has a few benefits to it. It establishes two separate functions to begin and end charge. It provides a variable to check for whether it's currently charging, which can later be used to evaluate the code with some sort of warning mechanism to remove redundant calls. While still proving the amount of Charge in a short variable name.

For one, it usually belongs to the part where you do the specification to find proper and clear words to describe the details of your project in a precise and unambiguous manner. If you have a well done spec, the glossary might actually be helpful in finding a synonym for either the verb or the noun.It should also usually be no problem to just think about both use cases and find a more precise or more broad word that still is functioning well enough for one of the cases. Often those names are logically connected to things that might make sense just adding as a part of the variable name. While not being a native speaker, "BatteryCharge" seems totally a noun for me, "chargeBattery" rather not.If all that is not an option and Hungarian Notation, which I dislike personally, is not your cup of tea, then there is always the option of using unobtrusive modifiers. One example was given with putting "do" in front of the verb. Another option is to put articles in front of the nouns.

Who says the area at question is hardware? It is FAR more likely that the 2 uses of 'charge' to OP is talking about are financial, where you can have "a charge" which you can "charge to" someone/something. In that case there are plenty of words that can be used in place of the noun, such as 'transaction', etc. However it is often good to stick to domain standard terminology. I think something like "doCharge()" is perfectly fine for a function in this case.

Honestly though, is the duplication really a problem. How often is a method/function going to get confused for a type/class? Call them both charge, don't worry about it, and stop burning $100 an hour programmer hours on it.

If your language requires parentheses behind function calls, then I don't see what the problem is, unless you're supplying functions as arguments, and even then, the type system will typically prevent or else reveal any ambiguity.

While most computer languages are context insensitive, a bit of context sensitivity is not a whole lot to ask from computer programmers.

Why I didn't write GeneesMiddel or MaatSoort is something only Dutch and German people probably will understand But usually all code is written in English anyway because stuff like GeneesmiddelRichtlijnFactory, or worse, GeneesmiddelRichtlijnFabriek are just too ugly and break your code flow.

In Java you might use setters and getters, but not in languages like Ruby.You also would never see Hungarian notation in idiomatic Ruby (among some other languages).

I think the second answer is the best one. A battery does not charge itself, you use a battery charger for that. It makes the intent clearer, and keeps the concerns of charging the battery and know what its charge is separate. As a solution, it'd also be acceptable in any OO language regardless of the idioms.

1) Is the problem ambiguity in the programming language? Would the compiler be unsure of whether to invoke the function or work with a value? I use nouns and verbs all the time, but even natural language grammar is sufficient to disambiguate in most cases, given a bit of context.

2) Is this a real problem in the real world? If you were using a post-1980s development system you could just hover your cursor or click a keystroke and have the computer resolve the ambiguity for you. It's not the 70s anymore. I used a very nice C++ / Emacs mode that handled this very nicely in the mid 80s. Surely we haven't been moving backwards that quickly.

NOTE TO AMERICANS: Herein lies a practical reason why you shouldn't use verbs and nouns interchangeably: it leads to real confusion, misunderstanding and an increased rate of technical difficulties.I would be a wealthy man if I had £10GBP for every time someone had sent me "an invite" (s.i.c., what happened to the word invitation?)I endorse the solution implicitly suggested in the first paragraph of Kevin Cline's answer: let's augment the language with a richer meaning, at least until we eliminate ambiguity. Let's be thoughtful about how we use our language. Let's restore our language to its former glory, and [flamebait]stop reducing it to a form of pidgin English[/flamebait].

I also don't see this as a huge problem (read: I've never had this problem), but my solution would be to implement a practice where verbs are left in their infinitive. In English this makes for some awkward names, but it removes the ambiguity completely.

battery.to_charge(); // call to charge the batterybattery.charge; // reference to get the state of charge

Of course in this example I would privatize 'double battery.charge' and use battery.get_charge() and battery.set_charge(), but it serves the purpose.

Hungarian Notation at a low level (to indicate basic type like int, string, etc) isn't needed in strongly typed languages. Especially in environments where you have extremely powerful IDEs that can take you right to the variable declaration.

In a type safe language, Hungarian Notation can be used for higher level purposes. Instead of naming a variable to indicate a basic type (int, string, etc) use it to denote a higher level type, like Html safe string, or SQL safe string, or JSON safe string, URL escaped string, Unsafe string, etc.

I wish our type systems or maybe our frameworks were evolved to enforce this. That way you couldn't assign a raw string to a variable of Html safe string, or pass a raw string to a function requiring a SQL safe string, for example. All such assignments would have to go through a conversion function. A single common library function that does the conversion could then do more sophisticated parsing (not just regular expression searches). Functions that do formatting, such as "printf" type functions, could accept a Format string in the first position instead of a raw string to help minimize the possibility of format string attacks.

Even with this extra level of type safety, I would discourage building up the syntax of a SQL statement that partially consisted of user input. Instead use a parameterized statement.

It would be good if the templating systems that render pages (eg, JSP/ASP/PHP/etc) only accepted Html safe strings to be substituted into the template output sent to the browser.

Who says the area at question is hardware? It is FAR more likely that the 2 uses of 'charge' to OP is talking about are financial, where you can have "a charge" which you can "charge to" someone/something. In that case there are plenty of words that can be used in place of the noun, such as 'transaction', etc. However it is often good to stick to domain standard terminology. I think something like "doCharge()" is perfectly fine for a function in this case.

Honestly though, is the duplication really a problem. How often is a method/function going to get confused for a type/class? Call them both charge, don't worry about it, and stop burning $100 an hour programmer hours on it.

If that were the case, it's still not that hard to make the terms less ambiguous .Bill/credit/debit/authorize/capture/invoice/etc.

I wish our type systems or maybe our frameworks were evolved to enforce this. That way you couldn't assign a raw string to a variable of Html safe string, or pass a raw string to a function requiring a SQL safe string, for example. All such assignments would have to go through a conversion function. A single common library function that does the conversion could then do more sophisticated parsing (not just regular expression searches). Functions that do formatting, such as "printf" type functions, could accept a Format string in the first position instead of a raw string to help minimize the possibility of format string attacks.

Even with this extra level of type safety, I would discourage building up the syntax of a SQL statement that partially consisted of user input. Instead use a parameterized statement.

It would be good if the templating systems that render pages (eg, JSP/ASP/PHP/etc) only accepted Html safe strings to be substituted into the template output sent to the browser.

I prefer the Ruby approach.

Why should I give a damn about the type? All I want is for the object to behave the way I want and expect. If I want something that forces a particular string format, or HTML safety, then I'll create it. I don't want the compiler forcing it down my throat.