And No, i am not referring to single variables in loops or exceptions. Lets say pointer/struct names in large c ,c++ programs . Are there any languages where this type of naming is acceptable or is the norm. Or any constructs in c/c++ ( not iterators,loops) where it is implicit.

what is the general practice in handling such naming conventions ? would you change it? if so how would you change it?

If you are a team-project lead and some one raises an issue with regards to the naming convention how would you view it?

  • Why exactly is it a problem that the identifiers are single characters? – user1249 May 19 '12 at 13:48
  • 1
    This is a rant. Yes, single variable names are a problem. I try not to use i where a storyIndex will do. There exist re-factoring tools. C# has StyleCop, for example. – Job May 19 '12 at 13:51
  • @Job i am trying to understand if its an acceptable practice in some context or if not what level of difficulty is the task of changing it – Aditya P May 19 '12 at 14:14
  • 1
    @kevin cline, yes, methods need to be short, and I still maintain that a good variable name is better than i or a j; not so much better that I would change it in someone else's code, but better so that I would try to avoid i and j myself. Even when using 2D array - the way mathematicians like to index a matrix and the CS people would can differ - arguably rowIndex, colIndex are preferable to having i and j. The foreach can't iterate over 2 collections of same size at once and LINQ is a bit slower. I find that it is better to not use i and j - it can make code 0.2% better. – Job May 19 '12 at 18:07
  • 1
    @Aditya P, check out this question stackoverflow.com/questions/93260/… You must consider the human factor - programmers get territorial. – Job May 19 '12 at 18:23

Absolutely i would change them.

How to know if it breaks any existing functionality?

Just run your test suite after the change.

Ahh, no test suite. ok in that case add this reason to the list on the big board titled "why we need to have tests". Don't change anything, you're likely to break stuff (and in the process possible lose the chance to convince people that the stuff should be changed). It's kinda like wearing a seat belt. You don't have to... but I wouldn't recommend driving without it... something might break ;)

| improve this answer | |
  • Yes i am mainly looking at your edited case – Aditya P May 19 '12 at 15:05
  • How would you change them in a proper way? – Aditya P May 19 '12 at 15:12
  • 1
    I would add semantic meaning to them, for instance people_iterator instead of i, or person_name_attributes instead of a, etc. Ultimatly aim to have code that reads close to English. This also eliminates the need for most comments (which quickly become stale anyway). – Michael Durrant May 19 '12 at 17:37
  • Also note that tests not necessarily cover every situation. – user1249 May 21 '12 at 6:08

First of all, ANY code change risk introducing new errors, and hence the advantage of the change must be weighed against the cost of doing the change. This may even be downright vetoed by your superior for production software, if the module in question has worked correctly for years or even decades.

I agree that single character identifiers may require more effort to understand, but is it hard enough to warrant changing?

That said, refactoring is a good way to rename variables to something more telling. Most modern IDE's can do this for you. Be sure that the new name conforms to your local conventions, so the next maintainer after you do not have to repeat your efforts.

| improve this answer | |
  • So you would view this as a non issue in terms of understanding by a programmer ? – Aditya P May 19 '12 at 14:27
  • No. I did not say that. I said that changing existing code, including renaming variables, may simply not be allowed. In that case, add internal information (in form of comments) or external documentation (in form of Wiki). – user1249 May 19 '12 at 14:32
  • +1 I have been yelled at for making cosmetic changes to the code base. Not that my changes were bad, but it is very important to know what others on the team will think of what I do. – Job May 19 '12 at 14:34
  • @ThorbjørnRavnAndersen I gather you have experienced the bad of your teammates/juniors who broke the software due to their trying to change variable names. – Aditya P May 19 '12 at 14:42
  • 1
    @Dima, with All due respect, your way of thinking is inexperienced. Any code change invalidate all previous tests, which is MORE than just automated tests. This includes customer testing which is non-trivial in terms of time and money. Not wanting to change existing code without good rrason is not the same as it being unmaintainable_. – user1249 May 19 '12 at 17:05

If the name of a variable is a problem, either because it's not sufficiently descriptive, confusing, or for some other reason, then change it. It's that simple. Many IDE's provide refactoring tools that make such renaming operations a 10-second operation. If yours doesn't, you may have to spend some time with a global find-and-replace operation.

| improve this answer | |
  • And this would be a good way to not cause the code base to break? – Aditya P May 19 '12 at 13:59
  • 2
    If you change the name of a variable everywhere, why would that break the codebase? Put another way: if the code stops working, you haven't changed the name everywhere. That's bound to happen, and the easy fix is simply to finish the job. – Caleb May 19 '12 at 14:19
  • 1
    The really fun part comes when a local variable now shadows or no longer shadowed another variable. Could easily happen in a world of single character identifiers. – user1249 May 19 '12 at 14:33
  • @Caleb ive used the eclipse rename feature but some how that seems to be causing a lot of errors. am to assume its just about using this feature in a correct way? – Aditya P May 19 '12 at 15:02
  • @ThorbjørnRavnAndersen Ideally, someone should have noticed the latter situation due to the warning that the compiler likely produces (depending on language). Even so, replacing a with aBetterVariableName globally shouldn't change the situation since local variables named a will also change. The latter case (changing to a name that's already in use) should produce all kinds of obvious errors (again, depending on language) or at least warnings. Broad changes in any large program always carry some risk, but this should be among the simpler kinds of changes one might make. – Caleb May 19 '12 at 15:06

In my career I have discovered that coddling peoples' feelings is way more important than correct code. Some yahoo might be writing the most fucked up shit imaginable, using single character names like 'm' for map or 'c' for ...??

Suggesting that this should be changed can hurt feelings and create lots of workplace drama. If you're wiser than me you'll approach these situations carefully so your bosses don't start hating you. Writing code like that is really dumb and people don't like it being pointed out that they're doing dumb shit. You might have to learn to put up with working on shit.

So no, don't necessarily just change it. Put out feelers first, etc... At the place I currently work I suggested changing some code that took indexes to global arrays as parameters, grabbed the value at that index, and worked on that value to taking the value by reference and so being independent of global bullshit....I've been hated by the lead architect of the project ever since and it's cost me big time.

You obviously work in an environment where shitty code has been allowed to fester. The people who wrote it may very well still be around and in high positions. They can get really obnoxious at even the hint that what they're doing isn't perfection defined.

| improve this answer | |
  • The reason i was/am concerned is that for a new person to learn or pick up the code its gonna take a hell lot more time to figure out. Inst code - readability a common practice in maintenance and future proofing ? – Aditya P May 20 '12 at 2:24
  • 2
    @AdityaP - Sure, there's always reason to prefer good code over crap. You have to decide how much you care, how hard you're willing to fight, who's feelings you're willing to hurt, and whether or not any of that will even do a damn thing. Sometimes it's better to just shut your face hole and live with it. You have to decide which environment you're in and having gauged very poorly on that in the past...I'd recommend proceeding with care. – Edward Strange May 20 '12 at 7:41

Names of variables should be expressive. You, or anyone else on your team should be able to understand what the variable is used for from its name. If another developer on your team looks at your code, and asks you what this variable is for, that is a good indication that you should change its name.

From this follows that single letter names are generally a bad idea, unless it is something obvious like

struct Point
  int x, y;


struct Pixel
  uint8 R, G, B;

Remember, you spend much more time reading code than writing it, so saving keystrokes should not be your priority. This is especially true with modern IDE's, which auto-complete names for you.

And IMHO, making a variable name more understandable is a very good reason to change code. And you absolutely need a good suite of automated unit tests to be able to refactor without fear. See "Clean Code" by Robert C. Martin for details.

| improve this answer | |
  • I would add "z" as being acceptable when you're dealing with 3D coordinates. – Loren Pechtel May 19 '12 at 22:00
  • @LorenPechtel of course. I am sure there are other examples. – Dima May 20 '12 at 1:30

This is going to be unpopular opinion, but

  1. Please keep your single-letter variable names. They're necessary. For-loops should never have anything else for index variables.
  2. If your class names are single-letter names, you might need to reconsider them.
  3. Use the length of the identifier as documentation of how commonly the variable can be found from the code. If it is common, it needs short name. If it's rare, it needs longer name.
  4. Short name can be considerably more descriptive than long name. Think of math. Large amount of accuracy is needed in math, but still they're always using single-letter names for everything. The description of what each variable or constant is doing is actually not helping at all whenever the math is applicable in many situations -- it's a sign of abstraction when you can generalize it. Short name is more generic than long name.
| improve this answer | |
  • 2
    I would modify #3 a bit. The length of variable name should correlate with its scope. If the scope of the variable is a single function 5 lines long, then a single letter might be ok. If it is a global variable that is used in 100 different places by 20 different programmers, then its name should be very descriptive. – Dima May 20 '12 at 16:55
  • Generally, there is only one test to determine whether a name (of a variable, function, class...) is descriptive enough. Show your code to a co-worker and see whether she can easily understand it. If she asks you what a particular variable is, then you should probably rename it. – Dima May 20 '12 at 16:57

Programming style guidelines can be useful for the individual programmer, team and wider audience of your code.

There are lots out there, have a look and maybe adopt one or amend to suit your needs?




| improve this answer | |
  • Hi Jeremy, welcome to Programmers! The StackExchange sites strive to become a repository of knowledge for years to come. While the links you've posted are helpful, if they ever break, your answer won't quite be as valuable. Consider editing your answer to include a few highlights from the links in the body of your answer such that it's valuable for years to come. Again, welcome to our site! :) – jmort253 May 27 '12 at 4:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.