<div>Sorry in advance if Google Inbox messes with my code formatting below (can't there be just one good email client? I miss Mailbox)</div><div><br><div class="gmail_quote"><div>Michael Savich via swift-users <<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>> schrieb am Mo. 19. Juni 2017 um 20:54:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span style="background-color:rgba(255,255,255,0)">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 too many functions can obscure the fact that the code is meant to be executed at that time.</span></div></div></blockquote><div><br></div><div>In my experience, the most idiomatic and readable (and testable! if that's important in your context) way of doing this is to create extensions to group and encapsulate related functionality (example obviously won't compile but hopefully you get what I mean):</div><div><br></div><div>```</div><div>extension MyViewController {</div><div> override public func viewDidLoad() {</div><div> let something = processModelData(data)</div><div> let views = something.map { UIView($0) }</div><div> addRelatedSubviews(view)</div><div> }</div><div><br></div><div> private func addRelatedSubviews() {...}</div><div> private func processModelData() {...}</div><div>}</div><div>```</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span style="background-color:rgba(255,255,255,0)">Closures can provide much of the same functionality but I'm pretty sure inline closures have to have names and sometimes risking a bad name is worse than no name at all.</span></div><div id="m_2940117070897002054AppleMailSignature"><br></div><div id="m_2940117070897002054AppleMailSignature">Anyway, do you think that most Swift users are even aware that do can be used in this fashion?</div></div></blockquote><div><br></div><div>Yes, and sometimes it's useful, most of the time I've seen or used it myself I'd consider it a code smell.</div><div><br></div><div>This is just a personal preference but I find that more indentation is almost always harder to read than less. The aim is to reduce cognitive load ("Don't make me think").</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div id="m_2940117070897002054AppleMailSignature"><br><br>Sent from my iPad</div></div><div><div><br>On Jun 19, 2017, at 2:33 PM, Michael Ilseman <<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>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 and extracted into a utility component. Long function bodies with many do blocks could be a code smell.</div><div><br></div><br><div><blockquote type="cite"><div>On Jun 18, 2017, at 7:07 PM, Michael Savich via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br class="m_2940117070897002054Apple-interchange-newline"><div><div><div>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. </div><div><br></div><div>I'm wondering, why <i>not</i> use a ton of do blocks? Like, if I have a ViewController lifecycle method like viewDidLoad, I could segment it into out a do block for creating subviews, a do block for loading data into them, and a do block for adding them to the view itself. This seems like it would enforce grouping code tightly together.</div><div><br></div><div>Yes I could adopt a functional style of programming, but that has its downsides too, namely reading any functional code involves trawling through a long sequence of function calls. What I'm saying is, do blocks seem like a way to get many of the benefits of functional programming while maintaining the readability of imperative code. (Sorry functional programmers, I promise I love Haskell too!)</div><div><br></div><div>So I guess what I'm saying is… somebody talk me down from this ledge. Is there a reason I <i>shouldn't </i>refactor my projects to be full of do blocks? And can this usage of do really be considered idiomatic Swift? Or will most people reading my code be left wondering where all the try and catch statements are?</div><div><br>Sent from my iPad</div></div>_______________________________________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br></div></blockquote></div><br></div></blockquote></div>_______________________________________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br>
</blockquote></div></div>