3 ms·
Beginners tend to write long comments explaining what the code does, then as they progress the comments get shorter (because they can read the code more quickly
by gotofritz 10y ago
Beginners tend to write long comments explaining what the code does, then as they progress the comments get shorter (because they can read the code more quickly) and eventually come the realisation that
// gets bear count
function getNumber() ...
is not as good as just
function getBearCount() ...
Places where comments are still useful, IMHO:
- complex or clever code; e.g. when I use shift for division by 2, that tends to confuse some coders, or regular expressions in javascript (for some reason JS devs seem scared by regexp)
- strange requirements or bugs or other reason to do something in a weird way
- other places why it may not be clear what I am trying to achieve
- Nadya 10y ago>- complex or clever code; e.g. when I use shift for division by 2, that tends to confuse some coders, or regular expressions in javascript (for some reason JS devs seem scared by regexp) I've found I've never had to use a Regex in Javascript yet. Also I don't think anyone enjoys reading Regex. Writing it is a lot easier. :) Reading `/2` or ` * 2` is more intuitive than `<< 1` or `>>> 1`. Although I learned a new code obfuscation technique! ;) [0] Testing 2^39 and bit shifting is negligibly faster. At lower values (2^4) it is equivalent. For any multiplication/division by a higher power of 2 (2^2, 2^3, 2^4) they become equivalent in speed. 549755813888 * 2 x 1,526,678,336 ops/sec ±0.67% (97 runs sampled) 549755813888 << 1 x 1,562,645,566 ops/sec ±0.26% (99 runs sampled) 549755813888 * 16 x 1,552,125,291 ops/sec ±0.33% (100 runs sampled) 549755813888 << 4 x 1,530,867,164 ops/sec ±0.35% (98 runs sampled) This seems like a case of "being too clever" by trying to optimize something that the compiler can optimize itself.
- gotofritz 10y agoThere was a time when it made sense, but now I agree it's rather pointless