Sorry in advance if Google Inbox messes with my code formatting below
(can't there be just one good email client? I miss Mailbox)
Michael Savich via swift-users schrieb am Mo. 19.
Juni 2017 um 20:54:
> Yeah, it's all about balance to be sure. Though one benefit of do
Yes.
But: Only if it makes the code better.
I think that “understandability engineering” is just as important as “software
engineering”. Maybe more so. After all, code that we understand has a better
chance of working correctly than code that follows all paradigms but once the
developer is
Huh, I didn't realize you could nest functions like that. That being said, I'm
not sure the declare-then-use structure really appeals to me personally. I
might use it if the function was getting really long.
One last question: labels on do blocks. I know they are mostly intended to be
used for
> On Jun 19, 2017, at 11:47 AM, Michael Savich wrote:
>
> Yeah, it's all about balance to be sure. Though one benefit of do blocks is
> in functions that are tied to a sense of time. It seems to me that the in
> case of something like viewDidLoad separating code into
Introducing scope to manage lifetimes of local variables is a useful and
valuable practice. Note that it might also be an opportunity to refactor the
code. Any do block you want to introduce could also be a local function
definition that you call later. Alternatively, it could be generalized
So, something I did not know until recently is that do blocks in Swift are for
more than just error handling, they can also be used to tighten scope.
I'm wondering, why not use a ton of do blocks? Like, if I have a ViewController
lifecycle method like viewDidLoad, I could segment it into out a