I've recently switched off those to Cursor. More flexible tool, better interface.
end user doesn't care, if it don't work it don't work
Great stuff. Feature requests: non-wp login, accents, Bar lines, support for non-4/4, swung meter, search by pattern (e.g. write a kick snare pattern, find beats with same kick snare pattern to e.g. find inspiration for…
I feel like this indicates there's a market for traffic-spike insurance
Clbuttic is even the (Collins) dictionary-defined nomenclature for this effect: https://www.collinsdictionary.com/us/dictionary/english/clbu...
> the behavior has always been The ECMA spec only defines Javascript 1.3 and above. See this description for logical operators for Javascript 1.1: https://web.archive.org/web/20060318153542/wp.netscape.com/e...
> which might promote misunderstanding of the behavior This isn't a misunderstanding, binary logical operators in JS short-circuit like this by design. I believe && and || returned a boolean value in the past, but were…
what are the downsides
The `err, result` function signature implies the function is an asynchronously executed node-style callback, which can never return anything anyway. Well, it can return something, but nothing internal reads it and…
Post is referring to async programming in node's callback style (non-promise-based functions executed asynchronously) where return values cannot be captured even if you want to.
The `err, result` signature of the function indicates that it will be executed asynchronously, and thus the return value can't be captured by anything anyway.
The `err, results` params form the signature of a continuation-passing style "errback": function(err, results) { if (err) // … } It is assumed that this function will be executed asynchronously, and thus it's not…
why
It depends. Short, dense code can make the code more difficult to understand/change later, while overly bloated code can have the same effect. I often find inelegant, yet straightforward solutions are generally better…
> calls at the end can still fail and need handling… You can’t conveniently omit the mess that would be created for checking each of those. For the purposes of this post, it is assumed that any errors produced in those…
I'm trying to imagine worst case scenarios here, and at least in an environment like JavaScript, I'm struggling to see how a beginner being overeager with early returns can possibly create anywhere near the same degree…
> ... makes case analysis easier ... > ...making the code look less complicated than it actually is... > I'd rather emphasize the underlying declarative intent, the state machines, and pre/post-conditions. These…
If the return value is important: if (err) return void handleError(err) And in non-promise-based async JS, the return value is almost always lost/useless anyway so `return x` has no effect, might as well repurpose…
A big gotcha with `&&` as a guard in JS is that it can return any falsey typed value if you don't coerce the guard to a boolean. e.g. const check(cond) => cond && otherValue If `cond` is falsey, it returns `cond`. This…
Yeah no hard rules, agreed on this point, especially when the if/else body is short.
I've recently switched off those to Cursor. More flexible tool, better interface.
end user doesn't care, if it don't work it don't work
Great stuff. Feature requests: non-wp login, accents, Bar lines, support for non-4/4, swung meter, search by pattern (e.g. write a kick snare pattern, find beats with same kick snare pattern to e.g. find inspiration for…
I feel like this indicates there's a market for traffic-spike insurance
Clbuttic is even the (Collins) dictionary-defined nomenclature for this effect: https://www.collinsdictionary.com/us/dictionary/english/clbu...
> the behavior has always been The ECMA spec only defines Javascript 1.3 and above. See this description for logical operators for Javascript 1.1: https://web.archive.org/web/20060318153542/wp.netscape.com/e...
> which might promote misunderstanding of the behavior This isn't a misunderstanding, binary logical operators in JS short-circuit like this by design. I believe && and || returned a boolean value in the past, but were…
what are the downsides
The `err, result` function signature implies the function is an asynchronously executed node-style callback, which can never return anything anyway. Well, it can return something, but nothing internal reads it and…
Post is referring to async programming in node's callback style (non-promise-based functions executed asynchronously) where return values cannot be captured even if you want to.
The `err, result` signature of the function indicates that it will be executed asynchronously, and thus the return value can't be captured by anything anyway.
The `err, results` params form the signature of a continuation-passing style "errback": function(err, results) { if (err) // … } It is assumed that this function will be executed asynchronously, and thus it's not…
why
It depends. Short, dense code can make the code more difficult to understand/change later, while overly bloated code can have the same effect. I often find inelegant, yet straightforward solutions are generally better…
> calls at the end can still fail and need handling… You can’t conveniently omit the mess that would be created for checking each of those. For the purposes of this post, it is assumed that any errors produced in those…
I'm trying to imagine worst case scenarios here, and at least in an environment like JavaScript, I'm struggling to see how a beginner being overeager with early returns can possibly create anywhere near the same degree…
> ... makes case analysis easier ... > ...making the code look less complicated than it actually is... > I'd rather emphasize the underlying declarative intent, the state machines, and pre/post-conditions. These…
If the return value is important: if (err) return void handleError(err) And in non-promise-based async JS, the return value is almost always lost/useless anyway so `return x` has no effect, might as well repurpose…
A big gotcha with `&&` as a guard in JS is that it can return any falsey typed value if you don't coerce the guard to a boolean. e.g. const check(cond) => cond && otherValue If `cond` is falsey, it returns `cond`. This…
Yeah no hard rules, agreed on this point, especially when the if/else body is short.