-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Description
This is a tracking bug for moving the Blockly codebase to use === instead of == for comparison (in most cases).
Background
The Blockly codebase originates from a time when it was common practice at Google to use the equality operator (==) rather than the strict equality operator (===) for comparison. The reason for this is somewhat obscure but may simply be that == was introduced in the earliest versions of JavaScript (certainly predating the 1997 ECMAScript 1.0 standard), whereas === was introduced in ECMAScript 1.3 in 1999.
In any case, the version of the Google JavaScript styleguide in use at the time of Blockly's creation, targeting ES5.1, does not weigh in on the issue and in fact does not mention === at all, whereas the current version specifies:
5.10 Equality Checks
Use identity operators (
===/!==) except in the cases documented below.5.10.1 Exceptions Where Coercion is Desirable
Catching both
nullandundefinedvalues:if (someObjectOrPrimitive == null) { // Checking for null catches both null and undefined for objects and // primitives, but does not catch other falsy values like 0 or the empty // string. }
See this Stack Overflow post for more information on === vs. ==.
Proposal
Given that the future of Blockly doubtless involves an eventual transition to ES6+ and/or TypeScript and therefore the newer styleguides (JS, TS), I suggested that we consistently use use === for all new and revised code. In a recent internal team discussion this was met with general consensus, so I therefore propose the following plan:
At the beginning of 2021 Q3 we:
- Post a notice to the effect that new code (and code being reworked) should use
===from now on (except optionally in the cases noted above) in:- Our styleguide page.
- The Blockly Google Group.
- Anywhere else?
- Configure the linter to reject use of
==except when comparing againstnullorundefined.
As time allows:
- Replace existing usage of
==with===. This will mostly be a bulk search-and-replace, but code will need to be examined to ensure that where we were previously depending on=='s type conversions an appropriate manual change is made.