kasia in a nutshell

I find I do that more when I go back and refactor, rarely when I'm actually writing code.

Although, I do use ret more than rval.

conn? rval? rs? ps?

Come on... get real. Those variable names are FAR too long. Way too much effort to type.

What ever happend to good old x, y, z, and q? Ok, ok, if you INSIST, you can type the variables by adding an extra character ... x$, y%, etc.

Ironic you should like Java then. One thing that makes my eyes glaze over is code like:

DataRecordRow = DataLibrary.DataLibraryFactory.GetObject.GetDataRecordsetRow();

Oh, don't get me started on chaining calls in Java.. just cause you can, doesn't mean you should :)

kasia, you fake Java developer.
you're a C programmer, aren't you? :)

In fact, your choice of variable names are not intuitive.

rs, ps, rval??? WTF?

This is insanity personified. Why not go back to fortran with an 8K memory? As the other poster said, use q,r,t,y,_m.

These are fine for you. You know what they are.

Look at the difference between:

for( int i =0; i array[i] = 4;
compared to :

for( int atArrayIndex =0; atArrayIndex array[atArrayIndex] = 4;

Now the second one is really horrid if using a single for, but what happens when we nest?

for( int atRowIndex = 0; atRowIndex for( int atColumnIndex = 0; atColumnIndex matrix[atRowIndex][atColumnIndex].doSomething();

This is a million times more readable WHEN you come back to it.

your are only 4 line of code... I think that a misrefactored, development stage 70 lines method with vars names of 2 letters is almost unreadable.

As always the truth lies in the middle:

Connection conn = getConnection();
ResultSet rs = null;
PreparedStatement pstmt = conn.prepareStatement(some_query);
SomeLongAssObject toReturn = new LongAssObject();

or better!!!

org.hibernate.session session = sessionFactory.openSession();
SomeLongAssObject toReturn = (SomeLongAssObject)session.load(SomeLongAssObject.class,key);

It uses hibernate so it has to be better? Without knowing the context? In the immortal words of whoever.. oy..

toReturn is only more intuitive than rval cause you're used to using that.. and I'm used to using this.

And anyone who doesn't get that i, j, k are often use as array indexes in nested arrays skipped a few CS classes..

I usually go with a one to three letter abbreviation (depending on the number of data types in the language) for the data type (in lower case) then the rest of the name (first letter caps).

For example, I would likely make the LongAssObject variable 'objLongAss'. I guess my variables are closer to AM's and I have to agree with AM, Jason and Sammy: Your variable names are not intuitive.

'conn' and 'rs' are ok, only because I've seen these commonly used in examples across a number of languages. People will know what they are when they see them, but I would still use something else.

'ps' and 'rval'? No way. I would rather see:

return someLongAssObject;

then,

return rval;

At least I can look at that and know what we are returning. Otherwise I need to go on a hunting trip to find what rval is declared as in this function.

Poor formatting aside (no argument there), I would rather see the fictional variables then yours. In a bigger piece of code I have a better chance of knowing what I'm seeing with longer variables then a bunch of variables 2 to 4 letters in length.

Ok 'AM' is the guy with no name. To early to see that AM was part of the time and guy's name is NULL or a space...

Try working on a project with 30 developers, with a full third of them switching out every 6 months. There's nothing like picking up a piece of code that somebody who was only there for a few month wrote four years ago and seeing variables named:

opc_level_4
pver
mthf

or my favorites:

glac_1_1_3
glac_1_4_6
glac_1_7_9
glac_11_1_4
glac_11_5_9
glac_11_10_12

Anybody know what any of these things mean? I have no idea, but I've only been working on this project for a few months ... Maybe after I'm here for year, these names will be transparent.

When you're developers are only around for 6 months, you need to get productivity out of them quickly, which means they can't spend hours learning the intimacies of a piece of code enough for these variable names to suddenly become "obvious and clear". Good code needs to be clear to the newbie - the guy you just hired yesterday - not the programmer who builds the application from scratch by herself, or has been around for years and knows the whole system inside out, upside down and backwords.

As someone said, you're a C programmer under Java disguise. Long class/method/variable names are quite common in Java.

I don't find long names a burden to read, although they're a pain when developing using a normal text editor. Java usually requires something like Eclipse to work around this.

And once you have Eclipse, you can start refactoring your code automatically, which is when you'll never switch back.

> And anyone who doesn't get that i, j, k are
> often use as array indexes in nested arrays
> skipped a few CS classes..

I don't use these anymore either. I keep ALL my variables in a standard format (no use having a standard format for variables if you are not going to follow it). I might use intIndex or intCounter instead of i, j, k.

Just because you used it in school, doesn't make it good. Didn't you say once that kids out of school didn't know how to structure code? To me using i, j and k as variables is something you learn later in life is bad form.

Just my $.02

Oh goodie, it's a religious discussion! You know, next time someone asks me for book ideas, I think I have one.. "Programmers and their religious wars". It would be quite amusing, I'd think.

Maybe I should do rant part 2: If you're looking at code in an editor and you can't figure out from glancing at it what it's doing.. then you have problems. Either 1. sloppy formatting, 2. sloppy coding, 3. your methods are too freaking long.

It always amazes me how many Java programmers write what amounts to procedural code.

I'm not a C programmer in Java programmers-clothing.. I'm just very anal about how my code looks and considering I've been told by many that I write exceedingly readable code.. then it can't be all bad.

Paul: the objects I used are all standard Java libraries and the variable names are very commonly used. Pick up any java book, you'll see them.

I wish the designers of Java had added a little bit more syntactic sugar to the language, so that the compiler would expand "$ResultSet" (or some similar abbreviation--imagine the dollar sign being pronounced as "some") to "ResultSet $ResultSet" the first time it appears in a lexical scope.

There seem to be a lot of situations in Java programming where a variable is the only variable with that class in its scope, and once you know the variable's class, you pretty much can tell if it does. So what's the point of having all these variables that are just like class names except for their capitalization?

> The objects I used are all standard Java
> libraries and the variable names are very
> commonly used. Pick up any java book, you'll
> see them.

I can see some of those variables in VB, JavaScript, etc. books as well. *Shrug* Still doesn't help me know what's being passed back in your return statement, regardless of where its used.

As Paul said, when you have a number of people picking up the code at different times, you can't count on people reading the same books. As I said, I would not use any of your variables. Regardless of how many books it was in.

A number of consultant companies I've worked for\seen have a standard way of declaring their variables, no exceptions based on the number of times a variable was published. Over time, I saw the wisdom of this. There is no standard here, just some names you think is commonly used.

To me, if the names do not follow a standard format, then it will be harder to maintain the program in the long run.

As for the other rants, one at a time please. :)

Here’s my take, and that of many I highly respect:

A variable name’s length should be proportional to the size of its scope.

Ie.: a global variable needs a long, descriptive name, while a temporary variable in a three-line scope can be a single letter without much trouble. Also, descriptive names for loop counter/iterator variables are counterproductive in most loops; i, j, and k simply read better.

> A variable name’s length should be proportional
> to the size of its scope.

That will work until new functionality is added and a variable's scope suddenly increases. Then you are left with either not having a descriptive name or renaming the variable. Odds are most people take the lazy way and keep the non-descriptive name.

But I agree what you say is common and at least doesn't make me cringe.

PBW makes an excellent point: any decent company (or operation) will maintain a "data dictionary" that should define naming rules and conventions within the organization or on a particular project. There is no "absolute" answer to the naming question.

On the issue of books, however, just because it's in a book, doesn't mean it's good. Having had the joy of reviewing dozens of programming texts to determine which one a class will use for the next several years, I can assure you that there are many BAD texts out there, written by people with very BAD habbits.

It's not unusual, for example, for someone to write a successful book on C, then have the publishing company turn around to ask them to write a book on Java because that C book was so successful. Unfortunately, the author might not have any clue about Java, but won't turn down another book opportunity. Result: a horrible book on Java.

I've also seen many instances where someone who's been "in the business" for 30 years write a book that would have been perfect 30 years ago, but it totally out of line with modern practice.

Short story: just because it's in a book (or taught in a CS class) doesn't mean it's good practice. In fact, just because someting is commonly done, doesn't mean it's right! (I mean, how many people voted for Bush?) ((THAT should stir things up a bit)).

(Hey, I'm just trying to share the love, you know?)

> (I mean, how many people voted for Bush?)

Noooooo..... That's all this thread needs is Kasia's favorite troll!

Nothing to see here, please keep moving, nothing to see here...

LOL, just because somebody has a CS degreee doesn't mean they know what they're talking about. Just like what do you call the person who graduated in last place in their medical school? Doctor. Just like so many people naively voted for Kerry/Edwards.

With an editor that does autocomplete, what does it matter how long the variable names are? I'd rather see something that lets me know what a variable is, instead of "rval". Just by looking at rval, you have no idea what sort of class it is, etc.

George W. Bush had anal sex with Tinky Winky - and he was even wearing a condom!

(It's on the internet so it must be true).

Oh come on, everybody knows that was Clinton!

kasia, I'm all with you on this. People don't understand that code is easier to understand if it is symmetrically formatted. Our eyes looks for symmetry to understand, and we can help a lot by good formatting.

> People don't understand that code is easier to
> understand if it is symmetrically formatted.

Sure we do, that doesn't mean that you can't name the variables better...

FYI, some of the new editors formats the code for you. I've seen at least one editor that the above spacing Kasia used would not be possible, as the editor would 'fix' it. The code is readable by the use of colors and spacing.

Don't be silly. Clinton has sex with an intern, not a children's TV character. And he didn't use a condom - it was a cigar!

Argh. Initial as variable names (or even class names). Make it readable to those of us who mouth words. And odd alignments that jar against the surrounding code and have to be pissed about with whenever changing a name or introducing a try block. Grrr.

Suggest variable names: conn, results, statement and ass (I once worked for a company that worked for a donkey sanctuary, but I never had to so much as touch an ass).

Golly.

This is not a religious war - this is clearly a difference of opinion between people who have different ideas of what clarity is.

There's several key aspects of clear programming that some of the people here are missing:

1. Methods should NOT be 10 miles long. If you need a long variable because you don't reference it until 50 lines later or you don't know what type 'rval' is because the method declaration is 5 pages back in your editor, the problem is with your method, *not* with the choice of name. And in fact, something like rval *is* very clear. After looking at 50 methods all where rval is returned, it becomes pretty damn clear that when you set 'rval', you're setting what is returned. If some uniquely named thing is returned from every method, there is an order of magnitude more effort identifying what is returned.

2. Formatting *is* important. As Mats mentioned, the human brain is great at pattern recognition. If this causes you a bit more effort when you modify code, too bad. Code is read MANY more times than it is edited - Paul, are you suggesting that we should the tradeoff of legibility vs. ease of writing should be made in favor of ease of writing? Shame on you!

I'd say that formatting is even more relevant than the length of the variable name. The clear organization of her example was more important than the length of the variable names - but the shorter length of the variable names enables such clear organization more than variable names such as preparedStatement, jdbcDatabaseConnection, queryResultSet and objLongAss. In addition, your brain's time to process will be proportional to the length of the name, as will the effort to match the pattern. Which is quicker? Finding 'rval' in ( ps, rval, conn, rs ) or finding 'customerObject' in ( customerQuery, customerObject, connection, customerQueryResults )? Furthermore, there is an inherent loss of clarity when you have to break a single statement into multiple lines because you are doing something like

PreparedStatement selectCustomerPreparedStatement = c customerDatabaseConnection.prepareStatement(selectCustomerSQLString); ResultSet selectedCustomersResultSet = selectCustomerPreparedStatement.executeQuery();

3. The aptly-named Aristotle there was 100% spot on. If I'm writing a loop, give me an actual reason to use a giant variable name as a loop index. Since the loop should fit on the screen, i.e. be no more than 5-10 lines, it should be pretty damn clear that i is the loop index - I really don't need something like intLoopIndex to tell me that. If you're finding yourself scrolling back and forth to check variable names and types, you've gone past the point where it's time to refactor a chunk of code into another function/method.

5. Don't knock the C programmers. There's a lot to be said for typing efficiency, and there's a reason why many unix commands are 2 characters or so. Frankly, I am less concerned about there being a slightly longer learning curve for people than I am about treating senior developers as fools, and I am greatly concerned about the effect of 'point-and-click' programming on the capabilities of developers.

6. WHAT THE HELL HAPPENED TO COMMENTING YOUR CODE?! Yes, the code should be clear. But it is your responsibility as a developer to write clear comments! The clearest variable name in the world will still not tell you WHY something was done. I (fruitlessly in many cases) look to the comments for purpose, not to the variable names.

Anyways, I agree with Kasia 100% on this, though I fear it's a losing battle given the vast preponderance of 'helpful' IDEs these day - observe pbw's comments about the editor 'fixing' the code formatting. Great, just what I need, yet another tool that thinks it's smarter than I am.

Actually, 'rval' is not clear at all. My first thought when I saw 'rval' was "rvalue".

See here: http://cplus.about.com/od/cprogrammin1/l/bldef_rvalue.htm

Yes, I did figure it out, but the point isn't that I *could* figure it out, but that I *had*to* figure it out. If it had been clear, I wouldn't have lost that moment. Spellinig it out and saying "return_value" leaves no room for confusion.

-->Paul, are you suggesting that we should the tradeoff of legibility vs. ease of writing should be made in favor of ease of writing? Shame on you!

Isn't a short variable name by definition ease of writing? I'm against short variable names! I am saying suck it up, don't be lazy, and type a few more letters so everyone can understand what's being written. Clarity is the foremost concern.

Here's what I said:

-->Good code needs to be clear to the newbie - the guy you just hired yesterday - not the programmer who builds the application from scratch by herself, or has been around for years and knows the whole system inside out, upside down and backwords.

I agree with your points on formatting and commenting. These are key issues, but I don't see anyone debating them. I think we are all in agreement on that.

Kasia, why get so defensive, why not even consider other people's points of view?

Was I being defensive or just arguing my point of view?

Two questions:
Have you ever attended a source code review?
Did you ever had to apply coding style guides or follow coding rules?

Choosing a name for a variable is not merely a matter of length, it is a matter of quality: someone who did not write the code should be able to understand it.
The software I'm working on is developed by a group of >30 programmers and is intended to run more than a decade on more than 100k devices. So anythink that makes it easier to maintain source code under these circumstances is highly apreciated.
I think it was a good idea to raise the question, why people care so much about their varibale naming schemes, but I think you got a few ideas...
In the age of code-completion, who cares about name length?

> In the age of code-completion, who cares about name length?

Those who try to write easily readable code.

> Have you ever attended a source code review?
> Did you ever had to apply coding style guides or follow coding rules?

Yes.. on my current project I set the rules. But I've had the good luck of working with some excellent, like-minded people. This was never an argument with my co-workers. I do believe burt's post (the long comment above) deserves to be an entry all on its own. He explains much better than I why variable length is indeed important.

Well, I'm too unmotivated to write a long response, it being a Monday and all.

But in a nutshell, I do not agree with the general philosophy that all code should be written so any random developer can understand it - and it is not unreasonable that there be some non-zero learning curve.

Consider any of the sciences - if someone writes a paper on DNA sequencing, they assume that the person reading the paper has some background in organic chem, and in genetics, etc. They do not start by describing these things - they assume a certain level of knowledge.

I think the same is true of software. Software should be clear, legible, and understandable - but that is *not* the same as "able to be understood by any random person after looking at it for 5 seconds."

Conventions such as using simple, short variables such as i, j and k have existed for close to 40 years now. Other conventions may exist only within a certain project, such as the "Declare the return value at the top of a method, e.g. 'int rval = 0;' and return it at the bottom." that Kasia is talking about. But if a convention is logical and applied consistently, then it becomes very powerful.

Sure, the developer with a keen grasp of language semantics may for a brief moment confuse rval and rvalue - once. But when that convention is used in every single method across thousands of lines of code, it changes from a brief confusion into a powerful tool to define intent.

This is why it must be kept short - because of frequency. Things used frequently, for efficiency's sake, should be shorter than things used infrequently. If the time to read or type return_value were identical to the time for rval, such concerns would be irrelevant, but the times are not identical and the concern is not irrelevant.

It is for similar reasons that i, j and k are acceptable and typically even useful - because of the age-old convention of using them as loop arguments, code of this form is an accepted standard, and anyone with reasonable skill in the field will recognize something of the form pixel[i][j] as being within a loop and will quickly understand the context - there is no need to use absurd names such as pixel[intOuterLoopIndex][intInnerLoopIndex].

Oh well. So much for short :)

> Which is quicker?

> Finding 'rval' in ( ps, rval, conn, rs ) or
> finding 'customerObject' in ( customerQuery,
> customerObject, connection,
> customerQueryResults )?

First, if formatted neatly (which it is not here), I find no difference finding my variables one way vs another. Plus the goal is not which way is quicker to read, but which way is easier to understand. The two is not the same.

Even if I concede the point that really short variables are somehow easier to read, if someone (like Paul) comes along and can't understand it right away, what is the point of it being 'quicker'?

Lets look at this in the bigger picture...

Let say I'm trying to find a run time bug in the code that has something to do with one of the values being returned. To find it you have to look across 3 or 4 procedures...

Ok, in procedure 1 rval is an object, in procedure 2 rval is a string, procedure 3 a recordset...

Don't you think that some point as you are bouncing around the code having 3 (or more) variables with the same name, with different scopes and declared as different data types that it would be a bit hard to keep up? You can't change rval to oRval, sRval and rRval (for object, string and recordset)? That would be better right there. At least I would know what the variable is declared as.

Plus, today there are tools out there that:

1) Format the code for you (which makes this whole formatting point moot anyway)
2) Use color to make the code even more readable

These tools make using 'long' variable even more readable. The variables 'jump' off the screen at me, since they are one color and the code syntax is another color. If you are not using these tools, go get them. One person mentioned Eclipse as a start.

Years ago, you would have been right on. Today, this mode of thought, IMO, is behind the times. If you have weapons out there at little or no cost that make your life much easier and you choose not to use them... *Shrug*

As for the rest of the rants, I agree with Paul, no one is debating them. So calm down. There is no religious war here, we are just talking.

In the end if it works for you, more power to you. I think there are tools and methods out there that would improve the 'readablity' of your code and all we (me, Paul, Jason, Sammy, Sergio, Aristotle, dj,...) are doing are pointing out a standard that is common in the marketplace.

As someone who has done it both ways I say: 'Don't knock it until you try it.'

>Consider any of the sciences - if someone writes
>a paper on DNA sequencing, they assume that the
>person reading the paper has some background in
>organic chem, and in genetics, etc. They do not
>start by describing these things - they assume a
>certain level of knowledge.

Well ... it's really not the same. Yes, I do expect that developer we just hired to understand programming, but (s)he might not understand the products that need to be worked on.

The "background" you speak of would cover certain stylistic issues like chained method calls (as in thing.goober(blah).foo(nyuknyuknyuk) - please don't argue the style of THAT), but wouldn't at all help my new hire know what a DAPA or a DoDAAC or an NDC is.

As someone pointed out, however, the key to readability really is in the commenting. The whole issue vanishes completely if in Kasia's initial example she had:

SomeLongAssObject rval = new LongAssObject(); // return value

As for using i, j and k, no one here can tell me that they were never in the middle of coding some loop within a loop within a loop doing some piece of logic (or reading someone else's code), making function calls, etc, etc. You get called away from your code for an hour or two, and then sit back at your desk and looked at the code and said...

What the hell was 'j' again?

If this has never happened to you, well you have a better memory then me that's for sure. For the rest of us, using something a bit more descriptive then i, j, k works out just fine.