Honestly to me the whole tabs vs. spaced debate should have ended 20 years ago when editors stopped being little more than glorified wordstar clones. The whole issue betwixt them should have gone the way of the dodo the same time as ^K commands.

Why?

Because any decent text editor can reformat them on the fly, that's why! ANY modern editor should have options to convert tabs to spaaces and back, or how many spaces the tabs are.

I'm with you on prefering single quotes, but beware that:

1) in JavaScript it makes ZERO difference in how things are parsed.

2) Singles are invalid for strings in JSON.

As to your "conditional", or as the rest of the world would call it a "ternary operator" that's just being pedantic unless it's being split into multiple likes, and honestly if just adding them for clarity sake it would be much clearer/cleaner code if you put them around the condition itself, not the whole ternary operation.

When it comes to one variable per line, stop saying var on each and every blasted one.

Commenting what's used or available in global scope is a good idea. I often like to add comments to the development code (stripped during deploy) that define the arguments, (ACCEPTS), what globals it uses (REQUIRES), what if any globals it changes or scope locals it side-affects (CORRUPTS), and of course what it spits out as a result. (RETURNS)

Good commenting -- particularly when most of us minify our JS on deployment -- is never a bad idea. Just makes life easy for the next poor sod.

I disagree with the "always ==" but then I do a lot of "return as false or empty" where loose conditions are in fact important. But yes, if you know it's a static type === is best.

I'd probably annoy you there though, I'd create those in Yodish putting the static first. Minification usually does it anyways, and logically a static string should establish the used type faster than a variable. (since its structure would/should be a direct memory reference, not a name lookup to a pointer)

... and why the complex/convoluted

Object.prototype.hasOwnProperty.call(obj, 'prop')

When you could just:

obj.hasOwnProperty('prop')

Or are you worried it might not actually be an object so you're forcing the typecast?