Yes, but like with everything: Please don’t do that just because you can.
Like many features it can make things hard to read and debug, even when the intention might be to make things easier to read and debug. In some cases it means that you can just look at the block, simplifying things, while in others it means you have to keep in mind that they happen in the block.
Of course with iterations and changes of code the situation might change, so don’t just keep it like it is, just because it made sense at some point.
I think most people know how tempting it can be to over-use things you just leaned about.
The nice thing about lexical scoping blocks is that they automatically inherit everything in the outer scope, without needing to pass stuff as explicit parameters. That’s valuable when the code in those blocks has several dependencies. I find it particularly useful when wiring up dependency graphs.
Lexical blocks also yield control flow statements to the outer scope directly, so you can e.g. return an error from within them.
I was using it today for a test where I didn’t want to repeat an initializer. I supposed I should have just used t.Run() and created subtests instead, oh well.
Yes, but like with everything: Please don’t do that just because you can.
Like many features it can make things hard to read and debug, even when the intention might be to make things easier to read and debug. In some cases it means that you can just look at the block, simplifying things, while in others it means you have to keep in mind that they happen in the block.
Of course with iterations and changes of code the situation might change, so don’t just keep it like it is, just because it made sense at some point.
I think most people know how tempting it can be to over-use things you just leaned about.
Feels like that’s what you’d use functions for.
The nice thing about lexical scoping blocks is that they automatically inherit everything in the outer scope, without needing to pass stuff as explicit parameters. That’s valuable when the code in those blocks has several dependencies. I find it particularly useful when wiring up dependency graphs.
Lexical blocks also yield control flow statements to the outer scope directly, so you can e.g. return an error from within them.
Inheriting/altering the outer control flow is indeed very useful, hadn’t thought about that.
I was using it today for a test where I didn’t want to repeat an initializer. I supposed I should have just used t.Run() and created subtests instead, oh well.
I never really feel the need for this, because my functions are short, so they fill namespacing naturally.