Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
In this example I'm not trying to set one variable from multiple places. Rather, I'm trying to set two different variables once each that never change. They actually are constants.
Each variable also has a different type in TypeScript too. There is a base class between them, but explicitly specifying the base class on the let and then casting in the function calls adds extra scaffolding that I don't think is necessary and want to avoid.
I'm not worried about adding another stack frame TBH. Once upon a time there was a performance cost to extra stack frames (and to function calls, try/catch/etc.), but V8 has been optimized enough these days that this only matters for extremely hot paths. And if this were a hot path, I'd write it pretty differently anyways, after taking the time to measure it and prove it's a hot path in need of optimization.
Yeah, a place I've done this is in writing switch statements in reducers. The extra scope also closes over any intermediate values you have so you don't have to coordinate variable names between blocks. I do this routinely for all switch statements all the time for this reason. The semantics are more useful and obvious with the braces.
I'd like to see the profiling run that shows that an extra stack frame here and there appreciably impacts performance. I promise it doesn't matter. Optimizing for readability is usually a better return on your investment than trying to optimize for performance. Also keep in mind the compiler is doing a lot of very smart optimization for you. It's better at it than we are. Of course, things that obviously matter like N+1 database queries obviously matter. Stack frames in JavaScript though? I would not worry unless you're doing something very novel.
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
Depends. Probably not significant unless it's really hot code (ex parser stap).
That likely wouldn't be a significant deal breaker, just worth considering.
My main counter is, why increase complexity, making the code both harder to read and maintain when defining entry using 'let' is much simpler/easier to understand.
To each their own. I bias heavily toward simple/maintainable code even of it's not 100% semantically perfect. Ie avoid adding complexity unless it's 100% necessary.
Why not
let entry;at the top of the switch block?If you're trying to set a variable from multiple place, it's not a constant.
Adding a scope, requires another stack frame. Ie increasing overhead.
In this example I'm not trying to set one variable from multiple places. Rather, I'm trying to set two different variables once each that never change. They actually are constants.
Each variable also has a different type in TypeScript too. There is a base class between them, but explicitly specifying the base class on the
letand then casting in the function calls adds extra scaffolding that I don't think is necessary and want to avoid.I'm not worried about adding another stack frame TBH. Once upon a time there was a performance cost to extra stack frames (and to function calls, try/catch/etc.), but V8 has been optimized enough these days that this only matters for extremely hot paths. And if this were a hot path, I'd write it pretty differently anyways, after taking the time to measure it and prove it's a hot path in need of optimization.
Yeah, a place I've done this is in writing switch statements in reducers. The extra scope also closes over any intermediate values you have so you don't have to coordinate variable names between blocks. I do this routinely for all switch statements all the time for this reason. The semantics are more useful and obvious with the braces.
I'd like to see the profiling run that shows that an extra stack frame here and there appreciably impacts performance. I promise it doesn't matter. Optimizing for readability is usually a better return on your investment than trying to optimize for performance. Also keep in mind the compiler is doing a lot of very smart optimization for you. It's better at it than we are. Of course, things that obviously matter like N+1 database queries obviously matter. Stack frames in JavaScript though? I would not worry unless you're doing something very novel.
Depends. Probably not significant unless it's really hot code (ex parser stap).
That likely wouldn't be a significant deal breaker, just worth considering.
My main counter is, why increase complexity, making the code both harder to read and maintain when defining entry using 'let' is much simpler/easier to understand.
To each their own. I bias heavily toward simple/maintainable code even of it's not 100% semantically perfect. Ie avoid adding complexity unless it's 100% necessary.
I think defining using a
letis the harder to read and maintain option than my option, and going that path increases complexity TBH.