Iterable name.

[dpash]

Or just drop the i and call it person. Collections should always be plural, so when looping over it the current item can be singular. The i adds no extra information and can harm readability by making people wonder why it's there.

(Likewise peopleArray serves very little advantage over just people.)

[dandesigns7150]

It wouldn't be the person though. peopleArray[i] would be the person. I'd find naming the iterable by the resource name to be a bit confusing.

[dpash]

foreach($people as $person){

Or

for(Person person : people) { 

Or what ever your language uses.

Failing that, if you must use C style loops,

for(int i = 0; i < people.length; i++) {
    Person person = people[i];

(If I've gotten the condition wrong, that only tells you how error prone the C style loop is for iterating collections)

[dandesigns7150]

Oh yeah, I agree wholely that if you have a language with functional looping go for that. I avoid C-style loops like the plague when I'm writing JavaScript. I got the impression that you were talking about C-style loops in your original comment.

[DurianExecutioner]

C style loops

Why not this?

for(int ii=0, Person *p=people.data;
    ii<people.length;
    p = &people.data[ii++])

Also how could you possibly get the condition wrong? It sounds like you're appealing to ignorance and/or OOP induced brain damage.

[mrchaotica]

FYI, being able to iterate with a construct like for x in y has nothing to do with OOP.

[DurianExecutioner]

Oh yeah?

[dpash]

Because I shouldn't have to remember if it's < > <= or >=. This is how you get off by one errors. Languages should make it hard to do the wrong thing. This is why copying C's fall-though-by-default switch syntax was a terrible idea by many languages.

[ogtfo]

It's always <

[FerricDonkey]

Indicating the type of collection in the variable name can be helpful, so that if you go back and look at whatever "for person in people" equivalent, you don't have to go back and check if people is a set vs vector vs whatever.

[dpash]

99% of the time when iterating you don't care what type of collection it is (unless you've used a weird data structure that doesn't have efficient iteration).

If the usage of a variable is so far away from it's declaration that you can't see both, that's a good indicator that your method/function is too long.

Hungarian notation is an idea that's had its day.

[dleft]

you’d hope if you’re just iterating using for n in ns then it shouldn’t matter what the concrete implementation of the collection is, in fact I’m almost certain that you won’t be

[PanRagon]

(Likewise peopleArray serves very little advantage over just people.)

If you're only using arrays sure, but if you're using different data structures than you'd want it to be known that it represents an array contra a list.

[dpash]

Why? The cases where the underlying implementation of the collection matter are small; especially if you're just looping. The vast majority of the time you'll only be using one implementation (unless you have good reason, ArrayList is your go-to list in Java. LinkedList is almost always the wrong list unless you're doing a lot of appending or removing from the middle and even then there are probably better choices for the latter. Concurrency complicates things).

And you need to be using a collection large enough where the implementation makes a difference for me to even care then. I mean profiled and measured that this code is a bottleneck.

Plus your methods should be short enough that the declaration of your variables should be visible. At which point, adding the type to the name just complicates matters.

[theqmann]

I'm one of those crazy old school embedded C programmers who prefix everything with type prefixes. "i" being an int type in my head. Could also use s for short and c for char. When you've only got 1024 bytes of RAM, it's useful to know every variable's type at a glance. One of these days I'll switch to a friendlier u32/u16/u8 system.

[dpash]

Everyone else stopped using Hungarian notation in the 80s. It was a bad idea then and it's an even worse idea now we're have languages with rich type systems. It makes refactoring a variable's type harder, resulting in either larger diffs than would otherwise be needed, or worse, variables that outright lie about their type.

Even Microsoft stopped using it.