How to name variables

Question

• What rules do you use to name your variables?
• Where are single letter vars allowed?
• How much info do you put in the name?
• How about for exam

Answer 1

What rules do you use to name your variables? camelCase for all important variables, CamelCase for all classes

Where are single letter vars allows? In loop constructs and in mathematical funktions where the single letter var name is consistent with the mathematical definition.

How much info do you put in the name? You should be able to read the code like a book. Function names should tell you what the function does (scalarProd(), addCustomer(), etc)

How about for example code?

what are your preferred meaningless variable names? (after foo & bar) temp, tmp, input, I never really use foo and bar.

Answer 2

locals: fooBar; members/types/functions FooBar interfaces: IFooBar

As for me, single letters are only valid if the name is classic; i/j/k for only for local loop indexes, x,y,z for vector parts.

vars have names that convey meaning but are short enough to not wrap lines

foo,bar,baz. Pickle is also a favorite.

Answer 3

Updated

First off, naming depends on existing conventions, whether from language, framework, library, or project. (When in Rome...) Example: Use the jQuery style for jQuery plugins, use the Apple style for iOS apps. The former example requires more vigilance (since JavaScript can get messy and isn't automatically checked), while the latter example is simpler since the standard has been well-enforced and followed. YMMV depending on the leaders, the community, and especially the tools.

I will set aside all my naming habits to follow any existing conventions.

---

In general, I follow these principles, all of which center around programming being another form of interpersonal communication through written language.

• Readability - important parts should have solid names; but these names should not be a replacement for proper documentation of intent. The test for code readability is if you can come back to it months later and still be understanding enough to not toss the entire thing upon first impression. This means avoiding abbreviation; see the case against Hungarian notation.

• Writeability - common areas and boilerplate should be kept simple (esp. if there's no IDE), so code is easier and more fun to write. This is a bit inspired by Rob Pyke's style.

• Maintainability - if I add the type to my name like arrItems, then it would suck if I changed that property to be an instance of a CustomSet class that extends Array. Type notes should be kept in documentation, and only if appropriate (for APIs and such).

• Standard, common naming - For dumb environments (text editors): Classes should be in ProperCase, variables should be short and if needed be in snake_case and functions should be in camelCase.

---

For JavaScript, it's a classic case of the restraints of the language and the tools affecting naming. It helps to distinguish variables from functions through different naming, since there's no IDE to hold your hand while this and prototype and other boilerplate obscure your vision and confuse your differentiation skills. It's also not uncommon to see all the unimportant or globally-derived vars in a scope be abbreviated. The language has no import [path] as [alias];, so local vars become aliases. And then there's the slew of different whitespacing conventions. The only solution here (and anywhere, really) is proper documentation of intent (and identity).

Also, the language itself is based around function level scope and closures, so that amount of flexibility can make blocks with variables in 2+ scope levels feel very messy, so I've seen naming where _ is prepended for each level in the scope chain to the vars in that scope.

Answer 4

The rules I adhere to are;

Does the name fully and accurately describe what the variable represents?

Does the name refer to the real-world problem rather than the programming language solution?

Is the name long enough that you don't have to puzzle it out?

Are computed value qualifiers, if any, at the end of the name?

Are they specifically instantiated only at the point once required?

Answer 5

I like to prefix my variables with what they're going to be: str = String, int = Integer, bool = Boolean, etc.

Using a single letter is quick and easy in Loops: For i = 0 to 4...Loop

Variables are made to be a short but descriptive substitute for what you're using. If the variable is too short, you might not understand what it's for. If it's too long, you'll be typing forever for a variable that represents 5.

Foo & Bar are used for example code to show how the code works. You can use just about any different nonsensical characters to use instead. I usually just use i, x, & y.

My personal opinion of foo bar vs. fu bar is that it's too obvious and no one likes 2-character variables, 3 is much better!

Answer 6

I learned not to ever use single-letter variable names back in my VB3 days. The problem is that if you want to search everywhere that a variable is used, it's kinda hard to search on a single letter!

The newer versions of Visual Studio have intelligent variable searching functions that avoid this problem, but old habits and all that. Anyway, I prefer to err on the side of ridiculous.

for (int firstStageRocketEngineIndex = 0; firstStageRocketEngineIndex < firstStageRocketEngines.Length; firstStageRocketEngineIndex++)
{
  firstStageRocketEngines[firstStageRocketEngineIndex].Ignite();
  Thread.Sleep(100);  // Don't start them all at once. That would be bad.
}