Yeah, but it’s easy to overuse it. If your for loop is much longer. For a few lines I’d agree, don’t bother using something longer.
Code should scream out it’s intent for the reader to see. It’s why you are doing something that needs to be communicated, not what you are doing. “i”, “counter” or “index” all scream out what you are doing, not why. This is more important than the name being short (but for equal explanations of intent, go with the shorter name). The for loop does that already.
If you can’t do that, be more precise. At the least make it “cardIndex”, or “searchIndex”. It makes it easier to connect the dots.
I’d say except indices in general. Just bloats every line where you need to use them. Imagine writing CUDA C++ where you regularly add and multiply stuff and every number is referenced via (usually) 1-3 indices. Horrible.
Index can be useful but start looking for mapping and sorting functions. Or foreach. If you really must index, sure go use index or I if it’s conventionally understood. But reading something like for I in e where p == r.status is really taxing to make sense of
Honest question: is there a mapping function that handles the case where you need to loop through an iterable, and conditionally reference an item one or two steps ahead in the iterable?
Something like parsing a string that could have command codes in it of varying length. So I guess the difference is, is this a 1-, 2-, or 3-character code?
I have something like this in a barcode generator and I keep trying to find a way to make it more elegant, but I keep coming back to index and offset as the simplest and most understandable approach.
This would map arr and return halved values for elements for which the element two steps ahead is even. This should be available in languages where map is present. And sorry for possible typos, writing this on mobile.
I have a convention to correlate the size of variable scope with its name length.
If a variable is used all over the program, it will be named “response”. If it is <15 lines, then it can be “res”. If it is less than 3 lines, it can be only “r”.
This makes reading code a bit simpler, because it makes unimportant, local vars short and unnoticeable.
Using single character variable names is always bad practice
Except
i
right? Something likecounter
orindex
seems unconventional and unnecessarily verboseYeah, but it’s easy to overuse it. If your for loop is much longer. For a few lines I’d agree, don’t bother using something longer.
Code should scream out it’s intent for the reader to see. It’s why you are doing something that needs to be communicated, not what you are doing. “i”, “counter” or “index” all scream out what you are doing, not why. This is more important than the name being short (but for equal explanations of intent, go with the shorter name). The for loop does that already.
If you can’t do that, be more precise. At the least make it “cardIndex”, or “searchIndex”. It makes it easier to connect the dots.
I’d say except indices in general. Just bloats every line where you need to use them. Imagine writing CUDA C++ where you regularly add and multiply stuff and every number is referenced via (usually) 1-3 indices. Horrible.
Index can be useful but start looking for mapping and sorting functions. Or foreach. If you really must index, sure go use index or I if it’s conventionally understood. But reading something like for I in e where p == r.status is really taxing to make sense of
Honest question: is there a mapping function that handles the case where you need to loop through an iterable, and conditionally reference an item one or two steps ahead in the iterable?
Not that I’m aware of but that’s a condition where you’re thinking with an index. What’s the difference you’re looking for?
Something like parsing a string that could have command codes in it of varying length. So I guess the difference is, is this a 1-, 2-, or 3-character code?
I have something like this in a barcode generator and I keep trying to find a way to make it more elegant, but I keep coming back to index and offset as the simplest and most understandable approach.
In js there’s reduce. Something like
arr.reduce((result, currentValue, currentIndex, original) => { if(currentIndex < original.length - 2 && original[currentIndendex + 2] % 2 === 0 ) { result.push(currentValue / 2) } else { result.push(currentValue); } return result; }, [])
This would map arr and return halved values for elements for which the element two steps ahead is even. This should be available in languages where map is present. And sorry for possible typos, writing this on mobile.
In Haskell, you could do something like
map (\(thisItem, nextItem) -> …) (zip list (tail list))
Counterpoint: using anything other than ‘i’ as your index in a for loop in C or C++ is obnoxious as fuck.
At most I’ll go with ‘it’ for C++ iterators.
Unless you are implementing some mathematical formula. Then link the paper and stick to its variables.
I have a convention to correlate the size of variable scope with its name length.
If a variable is used all over the program, it will be named “response”. If it is <15 lines, then it can be “res”. If it is less than 3 lines, it can be only “r”.
This makes reading code a bit simpler, because it makes unimportant, local vars short and unnoticeable.
Why though? Intellisense helps you write out the full name. And instead of response why not call it whatever the data you’re expecting to be
I agree because it makes the code easier to follow in 6 months time.
Could you comment a couple of examples? At best some that signifiy the importance with them as verstra wrote.
Sometimes you’re just using it once and it’s blindingly obvious what it is
To be fair everyone with poor documentation thinks the code is blindingly obvious when they write it.
Hope you don’t write go :D
JavaScript, TypeScript, and C# babyyyy
Mostly agree. I’m ok with single characters in a one line / single expression lambda, but that’s the only time I’m ok with it.
I understand this conceptually, but there’s also a gremlin in my brain that wants me to make every line as short as possible.
Big same. Long feels complex until you go back later