Suggestion: Prefer iterators dependent on the variable's name

I figured out that for most complex code structures where I need nested loops due to performance, I can more easily read them once I chose to use iterators based on the variable’s (object’s or array’s) name. I typically use the leading character as the iterator (e.g. dataset => d) and a trailing l to imply the length (e.g. dataset => dl).

While I know that functional programming is easier to read (e.g. using Object.values(dataset).forEach((chunk, c) => {}) it’s hardly avoidable in timing-relevant methods and complex sorting algorithms that need performant behaviours (e.g. an update or render loop in a game engine).

Anyways, here’s an example. Let me know whatcha think.

BAD example

const dataset = [{ foo: [1,2,3,4], bar: [1,2,3,4] }];

for (let i in dataset) {
    let chunk = dataset[i];
    for (let j = 0, l = chunk.length; j < l; j++) {
        console.log(chunk[j]); // you get the point
    }
}

GOOD example

const dataset = [{ foo: [1,2,3,4], bar: [1,2,3,4] }];

for (let d in dataset) {
    let chunk = dataset[d];
    for (let c = 0, cl = chunk.length; c < cl; c++) {
        console.log(chunk[c]); // you get the point
    }
}

[vsemozhetbyt]

It may be not absolutely matched with Avoid Mental Mapping (and Don’t over-optimize). Maybe something like datasetPart and chunkElement?

And I don’t know if this is in the book (I have not read it, unfortunately). Do the repository creators accept tips not connected with the book directly?

[ProLoser]

What about dataItem instead of d? I’m still not sure what part of your example is the lazy caching.

I do agree about too many variables with bad names, but I feel like that’s a symptom of overall a bigger problem with your code organization and changing from i to d isn’t really going to be where the real impact could be had.