3 ms·
I've also used scopes for this: func DownloadAndVerifyThing(path string) error { var url string { // Build URL ... url = [..]
by arp242 3y ago
I've also used scopes for this:
func DownloadAndVerifyThing(path string) error {
var url string
{ // Build URL
...
url = [..]
}
{ // Fetch
...
}
{ // Verify file.
...
}
}
I don't do this very often (and I'm having trouble locating an example off-hand, although I'm sure there must be a few in my public code), but it can be pretty useful at times.
- _a_a_a_ 3y agoI have and do use this for my 'normal' code, but not very often. I tend to prefer breaking things up into functions (usually named, not lambdas). Where I do use this style extensively is in self-testing code: // set up data to be tested var fred = ... var cathy = ... { // check fred does something correctly var result = fred.reproduce(2); assert(result.length() == 2, "fred should have 2 children"); } This prevents variable result from escaping and contaminating the next test, which happened an awful lot before I started doing this. Then maybe better ways; suggestions welcome.
- whstl 3y agoA different pattern I like in Ruby is the assignment with begin...end: fred = begin user_finder = ... user_finder.find('fred') end Again, not always "self-documenting" as whipping out a new function, but useful if you need to separate chunks and keep the code linear. The only issue with Ruby itself is that the scope is not lexical, so you can still use `user_finder` outside the block above (linters can catch it, though). But it's still worth to separate code without having a brand new method.
- ramses0 3y agoBoth _awesome_ comments, I made a similar one up above, but hadn't considered the `testing` use case which is actually really really cool to "protect" your test scope like that. Almost like a fake "setup/teardown".