Skip to content

Instantly share code, notes, and snippets.

@chris-martin
Created December 9, 2013 17:11
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save chris-martin/7876084 to your computer and use it in GitHub Desktop.
Save chris-martin/7876084 to your computer and use it in GitHub Desktop.

@aredridel

Thought of the moment: I never use === in javascript. I find that every time I need it, I've made a boneheaded design flaw elsewhere.

‏@chris__martin

@aredridel === is a promise to the maintainer who comes after you that you knew what you were doing.

‏@aredridel

@chris__martin Heh. For me it's a signal that they didn't know what they were operating on.

@chris-martin
Copy link
Author

I guess I can sort of see how what you're saying makes sense, but at the same time I don't follow at all.

Suppose you're reading this code:

if (foo == null) {
    // ...
}

That translates to

if (foo === null || foo === undefined) {
    // ...
}

which tells me that the author either didn't understand what == null really matches, or understood it and doesn't know whether foo might be null or undefined.

@chris-martin
Copy link
Author

I guess this is actually the same debate as i > 0 vs. i != 0 to check whether i is positive in a situation where you know i is supposed to be a nonnegative integer. The i > 0 school of thought says it's a good cover-your-ass strategy because it works even when i is negative, whereas the i != 0 crowd says that writing i > 0 is bad because it just demonstrates a lack of confidence in the constraint.

@aredridel
Copy link

Hm. I think in that case, I'd prefer the i > 0 case, which seems contrary to my preference for ==, but let me explain.

=== really hints to me that there's three cases. "Exactly what I meant" and a yet-to-be-differentiated "something else of that type" and "uh what?" -- especially when it's used following a typeof check (which I see a lot in that style of code)

I'd rather the loose type ==, "value I was looking for, or close enough to not care" and "not", or "greater than zero" or "not". They're both conditions that imply a certain closure over the input space.

I also tend to look for meaning in code -- the i != 0 case really says 'not zero' not 'positive number'. If I wanted to clarify "number", I'd write Number(i) > 0, not typeof i == 'number' && i > 0. It's got a lower npath complexity and a clearer meaning.

@chris-martin
Copy link
Author

Hm. I think in that case, I'd prefer the i > 0 case, which seems contrary to my preference for ==, but let me explain.

Heh, I actually intended for i > 0 to be analogous to ==. I suppose it sort of goes both ways...

@chris-martin
Copy link
Author

the i != 0 case really says 'not zero' not 'positive number'

In the case where the anticipated type is "nonnegative integer", the meanings of those descriptions are identical, and in many cases neither is a more intuitive or valid phrase than the other.

@chris-martin
Copy link
Author

It seems like you and I are looking at the code from different angles. You're describing a perspective of "I've received some arguments, now how can I do what the caller probably wanted", and I'm saying "I'm going to define a clear API over particular types, and a caller that doesn't use them is erroneous".

I find it easier to think within restricted types, in a smaller space. Ultimately, in that sense, I suppose the question to me is moot. Because really all we're discussing is what the program's behavior should be when the behavior is undefined, and I don't think one ought to give that any thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment