for...of vs for...in vs forEach

## Two loops that look alike and are not JavaScript has two `for` loops that read almost identically and mean completely different things. `for...in` enumerates **property keys**. `for...of` iterates **values produced by an iterator**. The single letter is the whole difference, and mixing them up is one of the most common bugs in early JavaScript code. ## What for...in actually enumerates `for...in` visits the *enumerable, string-keyed* properties of an object — the object's own properties **and** the enumerable properties it inherits through its prototype chain. Symbol-keyed properties are never visited. An array in JavaScript is an ordinary object whose elements live under keys that happen to look like integers. Object property keys are always strings (or symbols), so the array `['a','b','c']` really has properties named `"0"`, `"1"`, `"2"` plus a `length` property. `length` is non-enumerable, so `for...in` skips it, but the indices are enumerable and get visited — as strings: ```js const arr = ['a', 'b', 'c']; for (const k in arr) console.log(typeof k, k); // string 0, string 1, string 2 ``` Because it is a property loop, it also picks up anything else you put on the array object: ```js arr.tag = 'meta'; for (const k in arr) console.log(k); // 0, 1, 2, tag ``` And anything enumerable that lives further up the chain. Built-in `Array.prototype` methods are non-enumerable, so a clean environment shows only your keys, but a script that does `Array.prototype.last = function () {...}` (an old, discouraged pattern) makes `last` appear in every `for...in` over every array in the program. ## What for...of actually iterates `for...of` does not look at properties at all. It asks the object for an iterator and consumes the values that iterator produces, so over an array you get the elements themselves: ```js for (const v of arr) console.log(v); // a, b, c ``` Because it works off iteration rather than property keys, `for...of` also works over strings, `Map`, `Set`, `arguments`, and DOM collections — and it does **not** work over a plain object literal, which produces `TypeError: obj is not iterable`. ## The string-index trap This is what usually surfaces the bug in review: ```js const nums = [10, 20, 30]; let sum = 0; for (const i in nums) sum += i; // sum === '0' + '1' + '2' -> '012' ``` `+` with a string operand concatenates, so the arithmetic silently produces a string. Confusingly, `nums[i]` still works, because bracket property access converts whatever you give it to a string anyway — which is why `for (const i in nums) sum += nums[i]` looks fine and lulls people into keeping the loop. ## Order For arrays, engines visit integer-like own keys in ascending numeric order, so `for...in` *looks* ordered. Once you add non-index properties or inherit from a custom prototype, the overall enumeration order stops being something worth relying on. `for...of` over an array is always index order, front to back, by definition of the array iterator. ## What to use instead, per shape - Array values: `for (const v of arr)`. - Array index **and** value: `for (const [i, v] of arr.entries())` — `i` is a number here. - Plain object keys: `for (const k of Object.keys(obj))`. - Plain object values: `for (const v of Object.values(obj))`. - Plain object pairs: `for (const [k, v] of Object.entries(obj))`. ```js const config = { host: 'localhost', port: 8080 }; for (const [k, v] of Object.entries(config)) console.log(k, v); ``` These `Object.*` helpers return only **own**, enumerable, string-keyed properties, so they sidestep the inherited-key problem that `for...in` has entirely. That is the reason most modern style guides say: use `for...of` with `Object.keys`/`values`/`entries` for objects, and reserve `for...in` for the rare case where you genuinely want the inherited keys too. ## The one-line summary an interviewer wants "`for...in` gives me keys, as strings, including inherited ones; `for...of` gives me values from an iterator. Arrays want `for...of`; plain objects want `Object.entries` plus `for...of`."