Some javascript developers say that “===” operator is always better than “==”. I disagree with that.
I find javascript a different language when you test-drive your code. Different rules and concerns apply.
If you test-drive your code, most of the time, the “==” operator is fine. It makes the code easier to read and it’s proved and covered by your tests. They way the API is expected to be used is expressed in your tests. Any usage you expect is expressed in the form of a unit test.
Handling optinal arguments is a clear example of shorter code:
function someFuncWithOptionalObjects(arg1, arg2){
if (!arg1)
arg1 = someDefaultValue;
...
}
I don’t mind if “arg1” is “null” or “undefined”. “Falsy” expresses the concept better than “null or undefined” and the code is shorter. If I am test-driving this function and I expect the arguments to be objects, I don’t have to worry about “arg1” being a boolean with “false” value. That is not the way I am going to invoke this function. So I don’t need the “===” operator.
Now, If I am writing a framework, the rule might change. If I think that somebody else might pass in a boolean as the first argument, then I have to address this case. But I would ask myself first, why is my code confusing the consumer so much. Why is my code not expressing the intent clearly enough so that other developer is passing a boolean rather than an object.
Functions should have no more than 2 parameters, maybe 3. And they should be no more than 5 lines of code, maybe 7. The name of the function should communicate what it is intended for. Apart from that, I am test driving my code. So why do I need the triple-equals operator?
I guess that triple-equals operator is great when your functions are longer than 5 lines of code, or take a big list of parameters or have a confusing name.
I understand that this is not always the case. Writing a base framework like jQuery requires the triple-equals in many places for sure. But you don’t write frameworks all the time, do you? I write applications more than frameworks.
Our team is currently developing a framework with emerging design. We are basically adding features as we need them, test-driving the desing. And even in the framework code, we rarelly use the triple-equals. However, we care about wrong API usages, so we try to respond the consumer with human readable error messages that help him understand the mistake. This time, we care about incorrect usage and not only the cases we designed the framework for. But this goes beyond the triple-equals. And it is because frameworks are so horizontal that they can be used in many ways.
In my opinion, Javascript best practices don’t make sense without context. So far, the more important questions to me are:
– Are we using TDD to evolve the design?
– Are we writing a framework or an application? Business rules or architecture?
– Are we trying to write clean code or spaguetti?