Hacker News Reader

Comment by jdmichal | Hacker News Reader

`i` vs `index` is whatever. `index` is better, but it's not like I'd bash someone for using `i`.

Using `list` is just bad. Your list (probably) holds a set of things that has a name. So name your list that. At the very least, name it after the type of things it's holding. Types are only declared once, but variable names are forever. Having to constantly look up the type of a variable because the programmer was too lazy to name the list of things as `things` instead of `list` is rather inconsiderate.

(Of course, there are times when you would use `list`. For instance, if you're writing a list sorting function, and you actually have zero context more than "yep, this thing is a list".)

View on HN

Index isn’t going to be consistent when you need a second iterator in a generic algorithm; people just don’t like the sound of jndex. Use “i” and “j” and “k”, or “idx” and “jdx” and “kdx” if you must, but please don’t use “index1” and “index2” and “index3.”

As you say, list might be the best name for a variable if the use context is generic. The same with iterators and such. But you really have to think ahead to keep the names consistent, complicated names work against consistency.

Well, if you combine the two together...

    List<Foo> foos;
    for (fooIndex = 0; fooIndex < foos.length; ++fooIndex) {
        Foo foo = foos[fooIndex];
        List<Bar> bars = foo.bars;
        for (barIndex = 0; barIndex < bars.length; ++barIndex) {
            Bar bar = bars[barIndex];
        }
    }

It would be immediately, visibly obvious if you accidently use `fooIndex` in the `bars` list. Good luck getting that with `i` and `j`.

That, of course, is assuming you even need the indexes. Otherwise you get this:

    foreach (Foo foo in foos) {
        foreach (Bar bar in foo.bars) {
        }
    }

You have more context (in that first example) and so the foo and bar indexes make great sense.

i and j really make more sense (as i and j) when used in their more mathematical connotation: indexes into a multidimensional array/object.

  for (i = 0; i < thing.length; i++) {
    for (j = 0; j < thing[i].length; j++) {
      thing[i][j]; // this is very close to the mathematical use of indexes
    }
  }

Makes perfect sense because i and j are being used to index into the same thing.

i and j would be poor fits for your first example because they don't index into the same thing anymore. You've introduced additional levels of indirection, to rewrite your first example using i and j (and illustrate why this is an awkward construct):

  for (i = 0; i < foos.length; i++) {
    for(j = 0; j < foos[i].bars.length; j++) {
      foos[i].bars[j];
    }
  }

It's not wrong, but it is awkward and unclear as the code grows larger it becomes easier to misuse i, j, and subsequent index variables.

=====

And of course, you're absolutely correct: foreach or equivalent is a better construct. It states the intent of the code, rather than the how of the code. This keeps your code closer to the semantics of your problem specification.

however I would skip j as it is too similar to i. Use k instead.

> `index` is better, but it's not like I'd bash someone for using `i`.

Thre's strong grounds for saying that `i` is better.

At least in a lot of the code I work with, `index` is most likely to be assumed to mean something akin to a SQL index similar - a data structure or module used for fast lookup.

Whereas `i` is universally understood to be an iteration counter or a position in a sequence. That's a well-known convention that goes back for hundreds of years, and that many (if not most) of us learned before we really learned to program, by virtue of its use in math notation.

That is strong grounds for saying that `i` is likely to be well understood. Which is why I would not even bring it up in a code review. (Unless there is nested looping with multiple indexes, in which case I very much want better names to help prevent mistakes.)

And yes, words can have many definitions. This is where you actually do rely on context for the reader to separate. And I have zero issues with local conventions overriding global conventions. So if you really do have a lot of confusion between whether an integer means an array index or an SQL index, by all means create convention to disambiguate.

(Also, while "hundreds of years" is technically accurate, it's probably not as old as you think. Euler was mid 1700's with his sigma summation notation.)

I don't say you should never use "customers" over "list", but the latter is often good enough. List is a good fit for a compact method which is doing something generic on a list or the context clearly specifies what is in it. It is of course a matter of what you are doing. The point is, that being very specific every time is likely overkill.

You keep saying if it's obvious in context, but context is a name for "one more damn thing I have to keep track of." Which is why I call it inconsiderate; you are forcing other developers to constantly have to build and maintain their mental context of what is going on.

"Oh, great... Here's another `list` variable, let me go see what it is this time."

I disagree. There's practically zero cost to writing "customers" instead of "list". The only time it really makes sense for it to be "list" is when you're writing generic methods that just know it's a list.

Well, yes and no. I can see your point, but simplicity and recognisability sometimes are sometimes a trump card.

lst is actually a very good example. If you are writing small functions of less than a screen (which you arguably should be), and you can see that lst is a list of FileInfo, and the code to populate it in a function called GetAllWebConfigsUnderPath, and you have twenty of thirty other types of list generating functions, then seeing lst as the primary thing that gets filled everywhere is comforting and recognisable.

Having said that, having lstWebConfigs and lstAppleFiles and lstUnixFiles might be useful, for example.

Also, I assume you mean "type" as in "the kind of things that it is", rather than its actual type, such as integer, string, etc. lstInteger is largely pointless in this age of IDEs, but lstUserIdentifiers is demonstrably better (You shouldn't compare UserIdentifiers with StockCodeIdentifiers unless you work in H.R.)

Abbreviating as lst is just bad. You saved one character. And now people have to guess whether you meant list, last, localString, or first.

Yeah, sorry. I misread the original "list" as "lst" because that's what's used extensively here, and you're right.

When I said type, I meant type. Your example of "userIdentifiers" instead of "integers" is covered by my statement:

"Your list (probably) holds a set of things that has a name. So name your list that."

Yes. I was agreeing with you in that bit. Sorry I didn't make it clearer.

Reply on news.ycombinator.com