2

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?

7
  • Why exactly is it a problem that the identifiers are single characters?
    – user1249
    May 19, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 18:23

7 Answers 7

7

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

4
  • Yes i am mainly looking at your edited case
    – Aditya P
    May 19, 2012 at 15:05
  • How would you change them in a proper way?
    – Aditya P
    May 19, 2012 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). May 19, 2012 at 17:37
  • Also note that tests not necessarily cover every situation.
    – user1249
    May 21, 2012 at 6:08
5

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.

10
  • So you would view this as a non issue in terms of understanding by a programmer ?
    – Aditya P
    May 19, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 17:05
3

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.

6
  • And this would be a good way to not cause the code base to break?
    – Aditya P
    May 19, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 15:06
3

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.

2
  • 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, 2012 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. May 20, 2012 at 7:41
1

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

or

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.

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

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.
2
  • 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, 2012 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, 2012 at 16:57
1

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?

e.g.

http://geosoft.no/development/cppstyle.html

http://www.erlang.se/doc/programming_rules.shtml

1
  • 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, 2012 at 4:03

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