Hacker News Reader

Comment by thaumaturgy | Hacker News Reader

Here's mine, just for fun. I haven't seen anyone else using anything like it.

kVariable: A constant value, even in languages that don't support constants. Usually either a semantic shortcut for some value, or for some knob that can be turned at the top of the code.

xVariable: A local variable.

gVariable: Global. (I care much more about variable scope than I do about variable type.)

x, y, z, i, j, k: Counters. I try not to nest or overuse these too much. If it starts to get hard to follow, then I rename them.

There are a couple of other hints that I leave myself too. For example, I tend to pluralize the names of variables that contain arrays or lists of things: xWindowElements for example.

I never cared for Hungarian notation or its brethren. To me, it just had too steep of a learning curve for too little payoff, and didn't even convey the information that I usually needed.

View on HN

That looks to me like a variant of Apps Hungarian, encoding variable use. When you say you don't like Hungarian, do you mean more specifically that silly Systems Hungarian that encodes concrete data type?

Yeah, I was thinking more along the lines of Systems Hungarian.

After thinking about it more, I think I've decided over the years that problems like variable type should be handled in the architecture, not the variable names. If encoding your variable types in your variable names is doing you any good, then either your functions are getting a lot longer than they really ought to be, or you've got more globals than you should, or you aren't correctly handling objects.

I think this is true even for Apps Hungarian. It looks like Joel's article [1] is one of the most-cited resources on Apps Hungarian, and the specific example he uses is for signaling safe versus unsafe strings in a web application. He comes up with a somewhat convoluted example of why you might want to keep an "unsafe" string around, but I don't buy it. Every single input in a web application (for one example) should be vetted before any processing on the input takes place. You might not want to HTML-encode a string going to your credit card interface, but you certainly do want to validate it.

This is actually even more the case in things like traditional C/C++ applications, because the code bases get so much larger than the average web application. By the time you get to inner functions, they shouldn't need to care whether the input is correct or not; it should have already been handled elsewhere.

The one exception to this -- in my case anyway -- is in resolving variable scope. If I'm starting to use too many globals, it's hard to ignore lots of "gSomething" all over the place. That's a signal to me that it's time to re-think what I'm doing. Likewise with the loop counters. Prepending "x" to local variables just reduces name collisions with other functions and objects and whatnot.

[1]: http://www.joelonsoftware.com/articles/Wrong.html

> I haven't seen anyone else using anything like it.

Isn't the point of adhering to a style so that others will already be familiar with it?

I have seen the kVariable style, and of course the iterator convention. I have never seen the other two, however; usually globals are denoted with all-caps and locals are just assumed (xVariable seems annoyingly superfluous). That's just my opinion, though — if I were coding in a language where your style was the most common, I would use that instead.

"gVariable" was common back in things like "Tricks of the Mac Game Programming Gurus" and the like, years ago. I think it's an old Pascal convention, but I'm probably wrong.

When working on others' code, I do adopt their style, including their braces and so forth.

But for my own stuff, my style is more comfortable, and I think that when other people see it, it's pretty clear what's going on.

I prefer not distinguishing lexically between e.g. constants and static properties / global functions (depending on the language features), etc. Many constants represent configuration choices, rather than actual mathematical or physical values that will never change.

Local variables are usually distinguished by starting with a lower-case letter, as the codebases I work with have global and method identifiers start with capitals. Global variables, to a first approximation, are never used: I have never known a case where the use of global variables wasn't regretted in the longer term. But a g_ prefix wouldn't be out of place if they must be used owing to an old codebase already littered with them.

As to "counters": for indexing for-loops, at best i through k are used - if more are needed, subroutines are used instead, so i through k can be reused. Other things that count have better semantic names than single letters.

Reply on news.ycombinator.com