<span style="color:#323232;">== same (after magic)
</span><span style="color:#323232;">=== same and same type (in Javascript)
</span><span style="color:#323232;">==== same and same type and same actual type (in the backend before conversion to JSON)
</span>
Like == but more strict. The == operator will do type conversion, so 0 == ‘’ will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.
One neat feature is you can compare to both null and undefined at the same time, without other falsey values giving false positives. Although that’s not necessary as often now that we have nullish coalescing and optional chaining.
I just tested and Terser will convert v === null || v === undefined to null==v. Personally I would prefer to read the code that explicitly shows that it is checking for both and let my minifier/optimizer worry about generating compact code.
The short answer is that your language needs === when it fucked up the semantics of ==, but it’s also too popular and you can’t fix it without breaking half the web.
It’s also important if you’re checking hashes (at least, it was - if you’re using correct hashing algorithm that isn’t ancient, you will not have this problem).
Because if you take for example “0e462097431906509019562988736854” (which is md5(“240610708”), but also applicable to most other hashing algorithms that hash to a hex string), if(“0e462097431906509019562988736854” == 0) is true. So any other data that hashes to any variantion of “0e[1-9]+” will pass the check, for example:
I did use md5 as an example because the strings are pretty short, but it’s applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who’s password also hashes to a magic hash. There’s not really a high chance of that happening, but there’s still a lot of hashes that do hash to it.
Nah, some MCUs have low power modes.
ESP32 has 5 of them, from disabling fancy features, throttling the clock, even delegating to an ultra low power coprocessor, or just going to sleep until a pin wakes it up again. It can go from 240mA to 150uA and still process things, or sleep for only 5uA.
This should be the new isEven()/isOdd(). Calculate the speed of the CPU and use that to determine how long it might take to achieve a ‘sleep’ of a required time.
I took an embedded hardware class where specifically we were required to manually calculate our sleeps or use interrupts and timers rather than using a library function to do it for us.
This was in 1985, on a ABC80, a Swedish computer with a 3 MHz CPU. So, in theory it would be much faster, but I assume there were many performance losses (slow basic interpretor and thing like that) so that for loop got close enough to a second for us to use.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.