How to encourage idiomatic usage of Combine

Recorded April 9th 2020 – watch the full episode on YouTube.

It's really easy to wield Combine incorrectly, using it imperatively by over using subjects. How do we encourage idiomatic usage of Combine?" Is there an idiomatic use in Combine at this point?"

Daniel Steinberg: There isn't. I've been asking both publicly and privately, I think we need Apple to issue an idiomatic use of Swift. We don't even have that. The community has sort of centered around some standards but there aren't guidelines how to idiomatically use Swift yet, and so Combine and SwiftUI certainly not.

"I think we need Apple to issue an idiomatic use of Swift."

Paul Hudson: That was I guess, SE-250, the Swift style guide that fell into flames shortly before Dub Dub last year and folks were saying, “Why do we need a Swift style guide?” And of course, a couple of months later, Xcode now can generate Swift code for you as you drag and drop around the SwiftUI canvas. It became critically important to know what kind of Swift do you want to generate. And of course, that never went any further sadly. I hope it does if it comes back and perhaps we'll see SwiftUI style guide or Combine style guide or similar recommendations for this is how we think as a creator of this thing as presumably a very large user of this thing, how we think you should write it.

“I don't care what the style is. Just I want us all to be using the same style. Erica Sadun wrote a book very early with Swift Style and it made a lot of sense to me.”

Daniel Steinberg: And if I remember correctly, the Swift style guide came out of the guy at Google who had written a style guide for them that was very well received and had been beat up you know the way you want something to be beat up before you adopt it. And so it was a very mature document. I know sometimes the community just freaks out.

Paul Hudson: Was it Tony Allevato?

Daniel Steinberg: Yes.

Paul Hudson: I know exactly what you mean. It's just one of those things that is very personal. We all have a style we stick to whether we like it or not, I hope, a consistent style and it might be fairly standard, but it might be one of those folks who puts closing brace then a new line, then else, then a new line, then an opening brace and I'm not judging you listener who does exactly that – but I am silently judging you. But these are all different style guides and it feels difficult to change your style guide sometimes because you're so used to doing it a certain way. And by moving to Swift, and Xcode was adamant that switch and case should be at the same indent level and I have never done that way. I was push case in one level, and I've changed the Xcode enforced way, the Xcode encouraged way and I don't think about it, but it does jar your brain trying to switch across style guides.

Daniel Steinberg: In that specific case, I can't remember what the explanation was, but I think Chris Lattner posted that there was a semantic reason for why it was different in C and Swift. That semantically, the switch in case meant something different, which is why they deliberately indented it that way. I can't remember it. So it didn't resonate with me, but I remember that there was some reason for it.

“SwiftLint and Xcode and other tools, when you have an API that's changing so fast, it's so hard to keep up. And so function builders aren't even baked yet.”

But more broadly, to your point, I don't care what the style is. Just I want us all to be using the same style. Erica Sadun wrote a book very early with Swift Style and it made a lot of sense to me and she gave history of how it was done inconsistently and I think Ray Wenderlich had a style guide. These were very useful. I do care where my curly brace is but I'll follow yours. You probably worked on code bases too where there's always some person and it's usually a guy that goes in there, changes to move the curly braces. And then they commit that. Come on.

Paul Hudson: As Stuff MC Manuel added, "SwiftLint is, of course very, very good for this. I'm not sure SwiftLint's quite ready for the SwiftUI era, though." I don't know what rules it has for things like property wrappers. I've seen folks put property wrappers like @State on a line by themselves and a line break and then private var whatever below it. And I don't do it that way. I put it all on one line but then equally, if I was using something like @objcMembers which is not a property wrapper, but looks like one, I've traditionally put that on a line by itself before my class and I haven't really thought about it. But now, I am thinking about it and I kind of want SwiftLint to say, “I’ll take over that mess for you. Don't worry about your PRs being all about style guides, here's just the important stuff. I'll take care of the formatting bits for you.”

Daniel Steinberg: SwiftLint and Xcode and other tools, when you have an API that's changing so fast, it's so hard to keep up. And so function builders aren't even baked yet. And so having the tools that handle function builders, for example, that's got to be tough.

Sponsor Hacking with Swift and reach the world's largest Swift community!