If you’re still fuzzy on how JavaScript functions actually work, this kirupa piece is a clean refresher without the usual hand-wavy nonsense.
It walks through the basics in a way that’s easy to follow, which is rarer than it should be.
“without the usual hand-wavy nonsense” is exactly why I still like kirupa’s old JS posts — they actually show the call/return flow instead of vibes. If you’ve got a specific “wait, why does this return that? ” moment, those examples tend to make it click fast. I remember learning functions from kirupa back in the day and finally feeling like I could trace the signal chain instead of just memorizing syntax.
The “call/return flow” thing is where return vs console. log finally stops being mysterious. I still see people do this and then wonder why their function “returns undefined” later:
function f(x) {
return console.log(x);
}
const y = f(42); // logs 42
console.log(y); // undefined
One tiny habit that helped me: for any function, ask “what value comes out if I delete every console. log? ” If the answer is “nothing, ” you probably forgot a return.
When you said “ask what value comes out if I delete every console. log, ” do you have a similar quick check you use for spotting cases where someone accidentally returns a console. log(. . . ) (or other side-effect call) inside a bigger expression?
my little “roguelike ” is literally: pretend console.log(...) is undefined (because it is) and see if the expression still reads like it’s doing something useful. if it turns into “nice, we return undefined” you just found the accidental bug.
i see it most in arrow one-liners and ?:/&& chains where someone wanted “do a thing then keep going” but JS is like “cool, your thing returns nothing.” i usually just de-one-line it and give the log its own statement so the return value isn’t getting decided by side effects.
Yo the “arrow one-liners and? :/&& chains” callout is so real — when you say you “de-one-line it and give the log its own statement, ” do you have a favorite quick rule for when you’ll still allow a one-liner vs when you force it into a block?
for me it’s mostly “can i read it once without slowing down?”
one line is fine when it’s just a plain expression and nothing sneaky is happening. the second i see && / ||, a ternary, or i want to drop in a console.log, i split it into a block and give the middle thing a name. feels cleaner to me.
