The panelists discuss code standards in Swift with David Mauro.

 

Well, it’s cold in Minnesota.

That's right here! Haven’t gone outside in two days.

Hey everybody! Welcome to episode 93 of the iPhreaks Show! This week on our panel, we have Andrew Madsen,

Hello from warm sunny Salt Lake City.

Jaim Zuber.

Hello from Minneapolis.

I'm Charles Max Wood from DevChat.TV and this week we have a special guest and that’s David Mauro.

Hello from freezing cold New York City!

Freezing cold huh?

Yeah! Yep – twenty degrees – so, not so nice out here.

We brought you on today to talk about code standards in Swift. So, have you been doing a lot of Swift out in New York City?

Yeah. I have been up – I would say – the Swift standard-bearer here at BuzzFeed because it just appealed to me from the start for a couple of different reasons. And I've been going gung-ho like trying to learn it in my free time. And now as we're moving some of our newer apps over to Swift, namely the news app that we're working on right now – pretty much all of my dev time lately has been in Swift.

And a big part of that process is nailing down how should we be writing the Swift code because everything’s new and it’s all a little different than Objective-C. It’s close enough that you can pretend you're writing Objective-C sometimes, but obviously, the syntax is different. And sometimes you just have to take a completely different approach. So, I'm thinking a lot about defining those standards so everyone on our team can work together coherently and learn the language together. So, it's a blend of learning and defining what we're learning at the same time.

Yeah, seems to me that in a lot of ways there was a lot more ceremony in Objective-C and a lot of that provided structure. And where Swift doesn't have as much of that. It also, then, doesn't have as much of the “You have to put things together in this way in order for it to just work at all.”

Yeah. Well, I think a lot of that too. It might be like the compiler is – has trouble sometimes because it's so early. And sometimes it’ll the things that seem like they should be right and it doesn't work. And I think that's maybe just Xcode playing catch-up at the moment. But yeah, there's definitely a lack of convention you have with Objective-C.

“I want to look at the style guide not to know how BuzzFeed does this. I want to know how to do this, period! Because I don’t really know because it's all new to me.” And so it serves a dual purpose there because of that lack of convention.

So, I have to ask. I'm looking at the style guide. First of, the preference to not use semi colons, I'm sold right there. But, to be honest it's like “Do it this way and not this way.” And I'm wondering – and I've had this conversation with other people but I want to have it on this show too. Why does it matter?

I would answer it for the same reasons that anyone else really would. It’s just – it’s two major reasons. And the first is just like it's nice to get everyone on the same page because it can be demoralizing to be writing code and knowing that like someone else on the team is riding in a completely different way and you get that broken windows problem. It’s just like things are a little off and that can be off-putting. But, I think – more important though is just some of these style questions they aren’t just aesthetic. They directly affect the quality of your code. And so addressing things like how to deal with optionals that have a direct impact on the performance of your app.

I think style guide just reduced my creativity. I don't agree with that at all. I’m just going to do my own thing, man.

Besides, it’s your code that’s the ugly stuff right?

Right. Everyone else is doing it wrong.

It’s not my fault.

If you stick with my style then we're all good. But one thing that style guide – people put importance on it. And the reason they do is they've done studies that if you have to think about where you put your spaces, where you’re putting your semicolons, what do you name things, that’s mental bandwidth you could be using for something else.

If you're working on a project for a number of weeks or months, you get “Here's how you use spaces; here's how you do capitalization.” And you’re not using your mental bandwidth thinking about those things. You just fly through them. And so, when you’re looking at the other people code, you know how it’s supposed to look. So, being able to understand what people are doing takes less bandwidth. So, you have more bandwidth to handle more important things like making things work versus trying to map different underscores to spaces to capitalization, things like that.

So, there’s a real benefit to having a style guide other than just preference.

So basically, what you're saying is that I don't have to make as many decisions and I’ve got this couple pound pattern matcher in my skull that if it sees a pattern then it doesn't have to parse it as much.

Yeah, you see it and like, “Okay, I know what that does.” And you can go through it and focus on the important things.

Yeah, I think that’s a great point and one of the great – the positive benefits working the Swift is somebody is not coming with preconceived notions of what a style that should look like at this point. Whereas, if you wrote an Objective-C style guide right now and you have to consider wide spacing and the idea of like: “Well, somebody might be coming in with a different idea of what wide space should look like. And, then it can be tough because then it's not just – you’re not thinking of it as like, “This tells me how to write it but instead it’s telling me a differently way to write it.” You have to learn a new style.

42] not think about it and help people run on the same page. If the community, as a whole, settles on more common standards that are similar to other style guides, I think that helps for the same reason. You know – you come in saying, “Okay, this all makes sense to me. I don't have to think about it.” As opposed to coming in like: “I don't know how to think about this. Please, tell me how to deal with these common problems.”

Looking through the style guide, some of these make sense from removing clutter or making the code communicate a little bit better, stuff like that. What I'm wondering, though, is – what are the criteria that you use for saying: “Do this and not that”?

Great question. My approach is it should serve one of those two points I mentioned before. And to some degree, I want to make the style guide very comprehensive. You don't want it to be too restrictive. But, I want to try to address all of the questions somebody would have. So, I’m putting myself into the shoes of the new developer who’s working on an app in Swift and they want to know – they’re thinking, “There's a couple ways I can do this. Which is the best?” And then it’s up to me when I’m defining these standards to decide what is the best and why it’s the best.

trailing closures or any closures and XCode right now. Autocomplete too – I like pretty noisy default. And I haven’t addressed this style guide but I much prefer a less verbose closure declaration – the variables being declared in that closure. For instance, when using masonry. I just simply put “make in” instead of declaring the type and the return type avoid etcetera.

And so, deciding whether or not to put that in – it’s a balance of “Well, I think this breathes a little better like this but autocomplete is doing it like this, so I don't have the answer to that question in that particular scenario. But other ones, they – where they converged where it’s like “Okay, Apple's doing it like this. This is –you should avoid unwrapping optionals all over the place because obviously it's just like not very safe. You should be using if-let where possible.” So something like favor if-let over force unwrap, it's a no brainer for this style guide. Because Apple's doing it, it makes sense. It makes everyone happy but at the same time, it's good to put it in there even though it's so obvious because as a new developer learning Swift, obviously you don't just know that of hand.

For the new developers, what we talked about? What optionals?

So, they're coming at like potentially not knowing at all what optionals are. They’ve read the Apple docs on Swift and they have an idea but how do use these? Should everything be an optional? Should everything be an implicitly unwrap optional? When do you choose what is? And so the optional being a type, which can be nil as a valid – it’s essentially like an Objective-C type where nil has a valid value for it. And Swift types can’t be nil unless they’re explicitly defined as an optional. And that’s – to nail that down for everyone that doesn't know – for the new developers, our team’s coming in, they read that and they get – you get that but it's not immediately clear what that means for writing code.

And I think example projects are great. Looking at other peoples codes, sometimes – yeah something as simple as like looking at why and how you use them in the style guide can answer a lot of questions you might have right upfront.

Yeah. For coming from Objective-C, just about everything can be nil. If you pass nil, then no problem. Call method on nil. Fine – doesn’t matter. With Swift, all of a sudden you realize, “Wait a minute we can’t do this. This is going to take our app down. We’re going to crash. So, it's important to – at least to find how do we handle that.

Yeah. And Swift will just – it won't let you simply call something on optional because that might be nil. And you did it as nil, you can't call say a method on it. But you could – if it's an optional, you could optionally chain it. And it will simply not call for you. So, how some options can be used similarly to how they are in Objective-C and that you can make a method call on it. Essentially not happen at all if it’s nil. But there are other times when say you’re passing it to another parameter that does not handle nil and you would need to unwrap it.

“This can crash your app. Be very careful with this.” It’s the Swift compiler or if it’s not the compiler – if you – during runtime, if you encounter nil, when it –when you’ve told it you won't, which is what you're doing that exclamation mark. Then, it’ll simply crash.

I just want to point out. One of my complaints has been some of the stuff related to optionals has resulted in really gross constructs where you have to just nest if-let's if you've got multiple optionals that you need to safely on unwrap and say end up with these nested if statements and – anyway, they've improved that in the new release that came out two days ago. So, they’re obviously looking at some of the problems that some of this stuff causes and thinking about how they can change the language to make code style better.

Yeah. And Jaim actually came up with a pretty – I don’t know if you came up with that or if you found that somewhere but Jaim had a pretty good solution to that where – just the other day we were parsing a bunch of JSON, which is a common scenario where you have a lot of optionals that you probably need to coalesce into non-optionals and how do you do that without horrible nesting. It’s just completely unnecessary and as you mentioned in the 6-3 Beta, they’ve addressed that, which is fantastic. But Jaim had a neat trick with using –switching over those optional those values because you can very easily just check if an optional has a value with dot some – S-O-M-E – meaning some value. And then handling the default case would be the – where you handle “Okay, one of these values didn’t work. What went wrong?” But it allows us to –with just a single – if the expected if and else indentations allows us to check many values at once.

Just a disclaimer, I totally stole that from Natasha the Robot, our guest from last week.

Oh, awesome!

JAIM: it’s in a blog post I’ll put it in the show notes.

Perfect.

I think it was a callback, but yeah that’s basically using pattern matching through a switch statement and if everything is as you expected and need it to be, then you can create your object and know everything is there. But with Swift1.2, I don’t know if I would use that as much because having multiple optionals is a lot – will be a lot cleaner. So, when I upgrade to Yosemite, I can fire up Xcode 6.3. But not just yet. Having it run pattern matching.

Yeah, I think we’ll probably want to switch to if-lets. But yeah and also being able to combine those with other with other expressions is really exciting too. So, there's definitely many times where I’ve wanted to do that and you instead have to rely on “if does not equal nil” and then force unwrap it within the if statement because you want to combine – you want to do an if-let but you want also to combine it with another bullion. I haven’t installed – I haven't tried out 6.3. I just installed it. I haven’t actually tried it. Looking forward to that for sure.

Yeah, I’m in the same boat. I want to try it but you can't really write code you’re actually going to ship anytime soon.

Yeah. So, I've been learning Swift and a lot of the stuff I understand, a lot of it I don't. But what I'm wondering is as I get deeper into it, at what point should I start worrying about the style guides? Should I be doing that from day one? Trying to write code that complies with the style guide. Or should I just be figuring out what will make the app go and then learn this stuff after I understand all of the concepts and language?

I think if I were starting now, I would absolutely want to look at style guides. I think Apple does a good job of – assuming you’re reading their documentation – I think they're doing a good job of pushing you in the right direction. But I don’t – I certainly don't think it would hurt to take a look at what the style guides out there are saying and see what's in common and consider what's happening. Assuming, you have the experience writing apps, this isn't going to be – you’re not learning how to program; you’re just transitioning from Objective-C. I think those style guides will tell you a lot about Swift that you might not get from the docs. Because, with the style guides comes an innate understand of – “We’ve been using Swift for a little while and here are the problems we’ve had,” or rather, “here are the solutions to the problems we’ve had.”

And maybe you don't know what those problems were but I think if somebody's put something in their style guide, they’ve either foreseen or directly encountered some issue with the code they're writing at Swift and then addressed it.

That makes sense.

So, I would, for sure, tell people to go out there and find whatever they can. From reputable style guides and see what they have to offer. Even if you don't read it over and over and internalize it, just get a sense of what's out there.

So, if I create a class and I want to use it, would I make it optional are non-optional as a default? How would we define our style guide for different cases?

Right. So, in talking about defining whether or when to use optionals, I think my answer to that if I were putting that in a style guide right now, is – it’s like the – we have in the style guide prefer let over var. And I think it would be – the answer would be prefer non-optional over optional. The reason being that, the same for both those answers, which is one adds more functionality, which you might not need. So, wait until you need that functionality.

In the case of var, mutability is the functionality you hopefully don’t need and in most cases, you don't. And with optionals, that functionality is the ability to be nil. And hopefully, you can design such that's nil is not necessary.

You could be porting Objective-C code over and stuff would make sense to be nil. And you might be tempted to make it optional but you probably really should re–evaluate that on writing Swift. Does it actually need to be nil? And ask yourself – I think this is something Jaim and I talk about a lot, is nil a valid value for this thing? Are you expecting this to the nil at times? And if not, then don't make it optional. But start with non-optional and see if that works for you.

I think, a lot of the times in the Swift I've written, which I haven't done a whole ton of it but I'm getting to write about a fair amount, a lot other times you have to use optional. It’s because you're interfacing with the frameworks in Objective-C where things can be nil. I'm really trying to push myself when I'm just writing pure Swift that's not doing that kind of interface to avoid optionals wherever possible.

Yeah, definitely! Applying the framework boundaries, everything is optional because it’s coming from Objective-C and they haven't written a framework in a way where we can know that it's not going to be nil. And nil’s not a possibility but what I do in – try to – things around the boundaries, you know it has to be optional but have a conversion layer where you make sure everything is as you expected to be. And if it’s not, you fail to handle the error. How do we handle it? Begin everything into a point where you have to check if it’s nil. So you can just use it. And that simplifies your code downstream. You’re not doing nil checks. You’re not figuring what’s happened. And when your optional checks, your question marks come down. So it's a benefit if we’re doing it that way but I just like to hear what other people are doing.

Yeah, and I think that's – you talk about that in practice. That's like that example we talked about before where we’re getting JSON from a server and we’re using swiftyJSON to help us out there. And that obviously gives us the optionals since that’s the JSON. Who know’s if it's going to have the value you're looking for. But, before we turn that into an object that we use, we do that is that pattern [inaudible 20:32] confirm everything is there before we define the thing. And then we then coalesce them into the types we want and we know that they have a value. I think that’s – I don't see why people – that won’t become a common Swift practice because I think the people that are moving to Swift now care about type safety. You’re not moving to Swift because your like, “Oh, I really want to rewrite this app entirely in a new language.” You’re doing it because you want your app to be safer and less prone to crashing and that’s the pattern that will help you build that app that you want.

That makes sense. Now, another thing you mentioned, let versus var in a style guide. So, how do those differ from Objective-C? Which one should we use?

Right. So, let is simply a constant and you have to define it right now. You have to define it as soon as you declare it. You need to give it a value and that value can never change. It has some other properties where if you, for instance, make it an array or a dictionary they’ll be immutable immutable arrays and immutable dictionaries as well. So, it's a little bit magical in that sense, which if you're around in the early days of Swift, that wasn't the case. It was problematic. So, let is just a constant instead of a variable. It’s pretty much any time you're going to declare something as just a value that you want to reuse, that's just going to be a let or even just like a simple reference to something for your own to make things clearer for yourself, you would use a let.

And you only really need the variable if you know that value needs to change. So, var is this like using a variable in Objective-C, you can adapt that value to whatever you need to as long as it's still the same type.

Sounds good. So, default to let unless you can't. Then, you use var.

Yeah, that's another thing they've improved in 6.3 beta is you can now declare let and then you don't have to initialize it on the same line. You can initialize it in an if statement or something like that as long as it gets initialized before it's used the first time. [Crosstalk 22:41]

Yeah, that's an interesting point too. That’s one – I’m going to – once that happens, I think that's a great thing to tackle with in the style guide that I’m working on is to – what’s the better solution? See, Apple has now offered that solution, which is great. But there was already the solution of you to say let and then your name equals n. You could do an immediately invoked function to declare the values that you could do logic in defining the value. And it's a little bit more verbose. But the upside is – you know when the declaration is all done. Whereas like in the 6.3 it’s more clever and that you could set the constant to whatever you want.

34]

Compiler–.

I think the compiler has to know more about what's going on for this new thing to work and hoping they checked – they analyzed the various code patterns and make sure you have not left one out but–

Yeah, I assume what it'll do is – again I haven’t played with it, is it will confirm that has a value no matter what once you use it but just – what they mentioned like it needs to get a value set before you actually use it. But I’ll have to play that some more. I’m just worried about getting – setting a value when didn’t really mean to, if that makes sense.

What is the question? If you create the let and you never initialize it and you never use it, we okay with that? There might be a [crosstalk 24:19].

What’s that?

Did it make any noise at all?

It never happened. So, it’s a good thing for a style guide. Can you do things that way? Do you want to? Are there benefits? I suppose maybe it can be optimized out in some cases? Who knows? Oh! We’re just talking about vars and lets and the new Swift 1.2 feature where you don’t have to set the value for your let on the same line. You could do it anywhere. Just do it before it’s used, which you need to [crosstalk 24:49] patterns, which we haven’t probably – which I haven't even thought about before.

Yeah! Honestly, I don't think we had it anywhere in the app that we're working on right now where we’ve needed house to have a let that is not immediately defined. It’s probably rare. But is the sort of thing what when it happens, you don't want that to be a var because, again, you don't need it to be. And I guess, that's what the idea of a variable's mutable and you don't want to accidentally mutate something that you know never should be mutated. And I think probably right now, I think that – and I think this is why Apple did that is people are using vars when they should be using lets. For that reason, even though there is a hack solution, which is to use the immediately invoked function.

Yeah. But the downside using var is whatever you’re using could change. So, class around a var and it gets changed, how do you handle that? That adds complexity in your code especially with an array. You’ve got some values and they get updated by the array and you don’t know. And how do you handle that? Do you write on the fly? So, if you have lets you can keep your code simpler which will avoid breakage hopefully. All in theory.

Yes. So, I guess – and I guess we’re touching on this – but one of the things that I wanted to talk about was the biggest challenges in defining a style guide and the paying points. And one of the things I haven't tackled yet that – and I think we're bumping into this, Jaim – is testing. I think optionals present a problem for testing that we’re playing with some different solutions right now that look promising. But, that's the stuff that needs to get addressed early on – have a style guide address that. Like how – what are some simple rules that we can lay out for our test? And I think that the problem that we're running into, specifically with optionals and testing, is you want to assert, for instance, an optional is equal to something. And XTC assert equal does not handle that because an optional is not equatable and then you run each case of – okay, well, let me – in that case, I'll unwrap – if-left unwrap that optional and test it. And then otherwise, I'll sail it. And it's just completely non-ideal because you’ve then taken a one-line piece of code and you’ve turned it into four lines with two assertions. But it's – you’re just trying to avoid your test crashing in the case of nil.

Yeah, it’s bad because when you're writing code to use in production, you verify things. They work as you want. For unit testing, you expect things to break sometimes because that's what they're for. But hope they don't take down the whole to suite, which unfortunately, you do if you don't handle your optional – optionals correctly.

Yeah. That’s – looking at – I know that's probably not the standard “This is how we test in a style guide” but I don't think it would be a bad idea to address that. Like, “Hey, you’re going to be writing unit tests in Swift. Here's some ways to deal with optionals because, right now, Apple doesn't really provide those.” And a key to like in simple way – you have to – it’s not a lot of code but you need your own assertion method that they don't provide right now.

Yeah, and there's a blog post where someone figured out a way to do the check and fail gracefully as he can still keep it in one line thing. We’ll put it in the show notes. But it’s useful technique. So you can just have the one assertion in your code and not have the [inaudible 28:23] if there’s failed stuff.

There’s something I wanted to ask about. It’s taking things in a little bit different direction, but I think beyond just questions of code style and formatting and all that, which has been around in every language forever, there's also this question of entire design patterns and methods of programming that Swift enables or at least makes a lot easier than Objective-C did. And how applicable those are and when those should be used. And I'm thinking a lot of functional programming in particular because Swift has a lot of features that are coming from functional programming and from languages that are purely functional like Haskell. And I’ve seen – I’m seeing a lot of excitement about these concepts. There’s a lot of people that are really diving into them trying to apply them to the code they write for their apps. And this started before Swift with reactive cocoa and that kind of thing.

But I wonder when does it actually make sense to use some of those techniques? Is there such a thing as going overboard? There’s an impedance mismatch between some of those and the frameworks. I just wanted to get your thoughts on some of that.

So, I don't have a lot of experience with functional programming. So, a lot of this is new to me. But I think one of the things – I mean I guess I'm jumping the gun on my picks here but one of my picks was the GitHub style guide. And what I thought was interesting is that they do, to some degree, address that. Well, not specifically functional programming. But they’re talking about using Struts over classes. And they talk about – instead of – basically, they say “avoid inheritance”. And I thought that was interesting that they included that in their style guide because you could argue that goes beyond style guide and that’s more like design philosophy for how they're building their apps. But I think that's pretty cool at the same time that they have decided that that's an important part of how they build apps. And they want to include that, and I think if you had strong ideas about how to make Swift better through functional programming methods, I don’t know – I think you can make a strong argument for, say, like building out a style guide that specifically addresses those. And says, “Do it this way. Do it this functional way rather than the way you've been doing it in Objective-C.”

I think the most basic example of that is For loop. Objective-C, get a For loop. If you don’t have one, you increment it. And with swift, you could handle it differently. So if you have it right, do an operational over it, you can do a map. Map or do these type things. So, that's one thing that – now you have two. So I can do this in two different ways. Which one would you choose? Which makes sense?

That’s one of the things that came to mind for me too – some of those. They're functional programming concepts but they're so small that they're useful.

Yeah. That's one of those – again like Apple – certainly is – like reading the documentation, it seems like, and I think we’ll get a better idea as we look at more Swift code that they're writing, but I think they're trying to push us towards those mapping functions. And I would say get on board with it just because if they're trying to get us excited about it, they probably know something about performance. But you might want to do that test performance on a few different common For loops versus mapping patterns, and see if it's really better because I don't have a good answer right now to say like, “Oh, the mapping function is better because of how – for this reason or this reason.” There's a few different – there are some nice things that can make – well, I guess there are some things that are nice about it and some things are annoying.

You can actually get – some of their examples are just so obscure because they use the variable or the parameter shortcut. Those dollar sign – zero dollar sign one, etcetera, parameter shortcuts. And those can – you can make a pretty obtuse mapping function that way that I think would like just make your eyeballs pop out of your head if you looked at it. And so, I would say avoid that. But in terms of using a mapping function versus For loop, I don’t really have an answer for that and I haven’t addressed that in the style guide that I’m working on, but I think my gut would be do what it seems like Apple wants you to do with the assumption that they probably want you do more performing – they want you to use the more performing option.

That makes sense. I know when I was doing C# - either C# two or three had the same type of thing happened where they introduced link into the language. So, before we did the old C style For loops. And now we had the option of doing link, which was very similar – had lot of the same functionalities, maps, filters, folds, that type of thing. And on one hand, you can make it clear what you doing. The other hand, most developers haven’t played with and don’t know what you’re doing. They’re like, “What is this wizardry?” So you can get hard to debug code that your team might not be able to understand. And as Dave said, like the dollar sign zero syntax is odd but it does work, I suppose but–

Yeah. Sure, I can see why they want it there. For the very simple cases of like I want to filter this in ascending order a like “dollar sign zero, greater than dollar sign one.” I get that. Looking at it like, “Okay, that makes sense,” and they want you to turn them into a one-liner. And in that case, it's like, “Okay, I can get on board.” But then you have to say, “Well, where do I draw the line?” If you – once you write that one simple mapping function that’s a one line mapping function, then you force yourself into a corner where you have to declare like, “Okay, this is too much. You need to now – like this can’t be in a single line. You need to break this out, indent it and use proper parameter names, et cetera.” But I know like in WWBC, I remember one of the talks about Swift was the developer on stage was very excited about trailing closures, and specifically the fact that they can be on one line and not have parameter names. And I was just mystified by it like, “Why are you excited about this jumble of code all on one line?” That’s seems so aesthetical to the – what I'm excited about Swift for, which is – one of the nice things about Swift is it’s so less verbose than Objective-C. That it can be sometimes it may be easier at a glance. And so, making things that are not easy to read at a glance, is – seems to go in the wrong direction.

Well, I have to say, I mostly do Ruby development so hold that against me if you wish but Ruby has a lot of these functional constructs in them. In fact, we almost never use for loops. We just use an each, which is an iterator, effectively. And then it just applies whatever block we have to whatever object is in the array or a numeral object. In a lot of cases, it simplifies the code beyond what the for loop does because you don't have to keep track of the iterator. It just does it on its own. And the other thing is it does allow you to have a lot of these other more powerful things like map and reduce and things like that, that building for loops to do each step is – it’s a different way of looking at things but you have – it’s a lot more overhead to do it – to think about. And so. I don't know that it's always the best way to do it or a better way to do it, but there are definite advantages to having both options in your tool kits so that you can think about the problem one way under some circumstances; and think about them in another way under other circumstances. And if you if you've worked in a purely functional language like Lisp or Scheme or Clojure or something, then you really start to understand the power of how it manages things, particularly lists. And the ways that those can pay off.

And the people who have a lot of experience with functional programming are going to be excited about this because they understand the power behind them. And the people who aren't – I think, eventually, it’s just going to become second nature to them to see “Okay, it feels natural now to use this iterator,” as opposed to a for loop with this big construct around what I'm trying to get done.”

I've definitely done three-page – three screen-fulls of for loops in my life because I had no other choice.

And that's painful right?

It was very bad. Nested for loops, four or five deep.

Yeah. I love the idea of having all those functional constructs in Swift. Overall, I think it'll be a nice thing to have. You’re not forced into using them either. So–

Exactly! That was what I was going to say. I think having that option there, I think it's important like if you're doing something where a for loop maybe makes more sense or you think would make developers more comfortable, that might simply depend on your team and where they're coming from. But if it's not going to be an unwieldy for loop, and the nice thing is you can say for variable name in an array and then you’re iterating through, you don’t have to track any iterator or anything. You just simply – given a scope with that variable you need to operate upon, that can be potentially the best solution. But yeah, I think having those options right now, I think is great. And so that's where the style guide comes in is helping to define those scenarios, in which the developer who maybe doesn't have as good of an idea of when to use which one, the style guide will help them get ready about. Sounds like you want to use a mapping function right now or sounds like a for loop would be fine. And just get them comfortable with either solution. And then, team is set.

Well, in your example of for – whatever in range whatever, under the covers it is doing the functional iteration that we just talked about. It’s just iterating over that collection in that way. Instead of basically iterating over – that your iterator’s keeping track of the index in a for loop instead of the object.

So what are the some of the other battlegrounds for Swift code standards? Tabs versus spaces – let’s settle those right now.

I know one that came up in a discussion with some people in real life recently, which is using self on property access method calls.

That's a great one. I found when I was first starting with Swift, my initial reaction was you should absolutely always use Swift. I already use self because it's so much more clear, and clarity is important. And I notice all the other style guides where saying avoid it and so I was like, “Well, I’ll give that a shot.” And I tried it I noticed, “Hey, you know what? The XCode colors these variables for me depending on whether it's a property on this instance or if it's a property on my super class.

” And I realize the clarity that self was adding was already provided by Xcode formatting.

Of course that assumes that the syntax coloring is actually working which is not a [crosstalk 39:24].

Maybe seventy – seventy percent of the time syntax coloring works I’d say.

That’s a real problem too. I’ve had that issue come up when I – my syntax coloring dropped and I'm still trying to write code and I was actually legitimately stymied by a variable which I couldn't tell what it's code was because–

Of course this assumes that we're always looking at code with Xcode and not github or gitdevs.

Well, the other thing is that, again it goes back to the conversation we've been having about context in understanding the conventions that are being used. Ruby has an implied self, so you don't have to call self but you can just like you're talking about with Swift. And eventually, you just get used to seeing something and assuming that it’s being called against self. And so, again, it's a standard that I think the community is going to decide on one way or the other. But it's really interesting to me to see what people are going to settle on and why.

I'd say one annoyance – if you’re to refactor and you’re putting something into a closure, then you have to add the self. You have to go back and forth. That’s the annoyance with that. But I think that–[crosstalk 40:35].

There’s is a clear tide against using self. So, I would say use self but I think I'm losing.

Yeah! And I’m in the same boat. And I – it’s a different question in Objective-C because there's actually a real difference between using self and not using self. They're not semantically equivalent but a lot of people didn't know that and I – it’s always been a crusade of mine to don't do direct instance variable access. And it’s – that's not the question in Swift. It really is just a style choice but maybe it's just my Objective-C background but self just looks right to me.

14]

Well, code mobility makes a lot of sense too. I was having a conversation with some of the guys on Ruby Rogues. And that was one of the arguments that somebody made for particular style of code was that – well, then I can copy paste and remove lines and it still works. And so, yeah if self is required in other scopes or closures, then it may make sense to keep it explicit.

So, on of the things that coffeescript does – I’ve written a lot of coffeescript because I really enjoy it. And one of the things I like about it most is it has a this more like a self, which is just the @ symbol. And you don't even need a dot after that. You just – if you had a property called URL, it would just be @URL. And that to me is perfect as it’s – it helps you immediately see – not only is it – are you talking about this? It reads different from when you're in the scope of a function. You’re using this to – you use @ at least when I write coffeescript I use it to specifically to refer to instance variables for that reason that it reads nicely and it's easy and self not self that’s like is like a long word. But adding self stop in front of something I think it's enough typing. And it's enough work to get there. It just – I think that’s why the community is going to end up going against it. It’s just like people prefer the shorthand version, and I think I’m usually all for clarity and I would normally be pro using self everywhere. But I think if the community is going to settle on not using it, I'd rather like also be there because I can – I think it can go either way. Like there's something like Jaim said, there's something to be said for instance, when looking at on GitHub and you don't have the color in of variables for apps but that was a tough call. I think I have so far decided to abandon self.

Well and if you don't need it and you can understand that it's there, than it’s noise right? It’s clutter. So, there are a lot of things to weigh in to this argument.

And do you know? The sun will rise no matter what we do. It’ll come up tomorrow. I can almost guarantee it.

You mean the sun rising doesn't depend on whether Jaim uses self?

No. That's more of the if-else for loops.

There we go.

You actually did bring up a good point about closures on self. The thing I like most about not using self is that it then requires it enclosures and you presented that as problem like an annoyance but I see that as a great tool for helping teach developers who maybe aren't aware of it to remind them like, “Hey, when it tells you to use self, there's a good chance you'll also need to make sure that self is unowned so you don’t get a retain loop. It’s a good reminder to – it’s XCode saying, “Hey, we're not going to let you apply this because it's important.” So I think letting that implication be there until XCode warns you, I think that's great.

Well, it's also a signal that there's extra context that’s been closed over.

Right. Yeah, I see that. Exactly. It’s like what you see is an annoyance, I see as a feature.

Yeah. You can't assume that you just have the basic scope. There's other scope here.

Yeah.

Good conversation. This is fun. So, I wanted to ask really quickly. It seems like most of the projects you build with Swift, they have a given structure as far as like where you put code. For example, I've been playing with Swift particularly with iOS. And so you put certain things in the view controller and certain things in some of your other areas. Does swift change the way that you structure your app as opposed to Objective-C in ways that you have to think about that Xcode doesn't just give you in the boilerplate app?

That’s a good question. I think, yes. I think like for MVC, not really no. But for the other stuff, yes. So for instance, and some of this is subject to change obviously because of things like class variables not yet being supported. But like Kevin, someone in our team asked the other day like, “Hey, I have no idea how to do a constant that we would you like this in Objective-C. How do I do this in Swift?” because there's obviously other ways to do it that might make more sense in Swift. If we have say a class that needs an associated constant that goes with it and Objective-C will just put that constant up above it in the same file. And right now, we're still doing that in Swift but that's only because class variables aren’t supported. And that, it would make a great case to be like, “Hey, this can be like a class variable because we could do like class let thing equals n.” And I think some other things that not cause us to write things differently, I guess, like how we’ve re–evaluated. How does scope are variables and enumerators I think that the fact that you can have enumerators without value caused you know it reconsider how you might do things. For instance, you might have had before a series constants that were strings and they represented something and you would then compare against each of those strings. But like maybe it makes more sense they don't actually have values and that's an enumerator and you can pop that into its own class on this enumerator with no values and then, and I think baby I’m getting game like too far out from the original question but I think the answer is there's things that do change out of – I would say like the MDC file structure stays more or less the same. But there's a lot of stuff we're still trying to get see what works best for us in and other areas as far as like where constants would go for instance. And I think maybe Jaim you probably have some more to say on this too. But yeah, it’s what I'm thinking as far as what's difference between file structure in Objective-C and Swift.

Yeah. I think a lot of it’s the same but I think part of it is before we head these global constants in Objective-C, how do you handle that? One pattern that's coming up is just creating a struct with a bunch of constants so we can standard typing that suit or places where dames face might do in a different language. So, that's something that’s a little bit different. So, you can have some typing with your little more type they do here. So that's been pretty company and useful. But I think the cone structure’s pretty similar I don’t see a whole lot different.

Yeah, except you get one file for every two in Objective-C. It’s a little – well, the little things.

So, I guess the other question is where do you see people messing stuff up as far as their style guide or the way that they put their code together that actually really affect the way that the code works, for the things that make their lives harder unnecessarily? Is there – I guess there's not really a standout thing if I'm not getting an answer right away. But–

Yeah, I think that the thing that immediately comes to mind. I think people are going to also you have to consider everyone's going to have different needs for their style guide. And I think as long as this somebody's considering different angles for how their style guide will affect the code that is written. I think as long as it's all been heavily considered, I don't see anything that will be like, “Oh, they messed up on their style guide.” It’s just make the decisions that are going to help your team write the code that makes sense for you. I got to mention the github style guide it says avoid inheritance so much like unless you need it, don't use it and someone might say, “Oh, that makes sense all the time.” But I think that’s partly has a lot to do with the code that you're writing whether it's a game or app. That would have major differences in the kind of code you want to write. So yeah, I think just nothing immediately comes to mind to answer the question. Just the idea of considering all the things when you put something in a style guide, if you’re writing, don't put it in there just because. like obviously with some place light spacing stuff, you just have to like habit like make a decision but I think for most things, it’s like have a good reasons for why it's in there if it’s in there. And if you don't know don't put it in there yet and have a conversation about it when the time comes.

I'm going to sound so smart next time I talk to somebody about this stuff.

Yeah! I’ve been with since the beginning!

Yeah you really shouldn't put your let's that way because. Anyway, I think we're pretty close to the end of our time. Is there anything else that we should cover that we didn't?

Well, I don't – this might be too big a topic but something that I've thought of is that with the elimination of header files in Swift; I like that change. But one thing that it does too that I am grappling with is header files were a nice way to document the public-facing API for given class and particularly if you're writing code for third parties to use like that you’re going to open source or whatever. They did provide a clean way to only expose the stuff that you wanted exposed. And Swift actually has stronger access control in terms of marking methods, public versus private. But as far as self-documentation goes, you don't have a header file so everything's in this big source file. In the implementation file and I'm not sure how to solve that so I wonder if anyone has any thoughts.

I do actually. And yeah I think this goes outside the scope of that I think like I don't plan to address this necessarily in a style guide. Obviously, I changed my mind decided we're going to do this all the time. But in one of our – I have a large core data manager class that's I was working on and have the same thought and I actually talked to somebody about this and he mentioned – we we’re talking about access controls and what they mean for just in general like writing stuff differently. And he mentioned using protocols for this very reason to replace header files and I’m trying that with this this large class I’ve got where there's a public-facing protocol. And the class implements that. Any documentation is associated with the protocol and any public file any public methods or properties are declared in the protocol. And there, it's all stepped out so you can add a glance get a sense of like what this class means to you via the protocol and then have plenty of other implementation details in the actual Swift file that the user of that class won’t actually see.

Okay. I like that idea. That’s actually really the only thing that I had come up with is to separate the public stuff out into protocol or even an extension so that you can actually separate parts of the class. But–

Yeah, the only downside to that then you have you have to look at the protocol in order to know what's in it, right?

Yeah. But that's actually the whole point is to have somebody who’s using the class without wanting or needing to know the implementation details. It's giving them a concise reference for the stuff they can use instead of having to read through all thousand lines of implementation. And parse out private versus public and figure out, which methods they can use, which ones they should ignore.

So, in my view it's a it's a way to document. Have the code be self-documenting in readable way.

Yeah, and the user probably wouldn’t know what that classes is. The type that you're declaring for your gadgets and stuff that are using that would be the protocol so that when they option click on there, they go to protocol not to class.

Yeah the only other thing that comes to mind though is that if you have a class that has a surface area that is so large that you can't look through the class and really understand what it’s trying to do, you are probably violating the single responsibility principle and you may want to look at breaking your code up.

Yeah, that’s a great point. For instance this core data manager that I’ve ported over from another app, I think it's a good example of something that it doesn't really make sense to break up. But it is a large file and it gets – I think it's like eight validly large file, which is why I don't think it makes sense to address this necessarily and the style guide because it's a rare scenario, but I wanted to give it a shot here. And I definitely agree. You probably should keep your vials small and put your public methods up top as a simple solution.

The only place that I've seen this where it didn't really make sense to break it up was there's a class in one of the projects that I'm working on with a client. And in fact, the client actually wrote that class. But, basically, what it boiled down to was – so it provided an interface – this isn't a web application – but it managed an interface on a web form and then it managed the workflow on the back end. And there's not really a clean place to cut part of it off and say this is clearly a separate responsibility. So yeah, I mean there are exceptions.

But in a lot of cases, I think it's healthy to at least look at it and say, “Yeah, there's this thing over here that's doing this particular job and it can go do it in some class.”

Oh, it's just like a Robocode Cop and go, “You are in violation of [inaudible 54:38].”

This code is not solid.

The next time that an app comes up in a pull request, I'm just going to put a picture Robocop up.

Superimpose my face on it. Thanks. Anyway, alright well let's go ahead and get to the picks. Jaim, do you want to starts us with picks?

Okay, I got a couple links. One was for the blog post we mentioned about unit testing optionals and how XC asserts does not handle optionals very well. So when I – first time I figured out how we're going to handle it by doing like an if XC assert and then a fail if the optional failed, I got mad and I tried to come up with an approach for tell your little cleaner. And I got close; I was missing the auto closure, but this person did a blog post about it and it's pretty cool. So two-way and I'm using it in live code just so you can have one assertion per test so Kent Beck won’t come to your door and Robocode Cop on you.

The second thing is I think I found the link to the article or the study I was referencing about chess recognition. They did a study where a chess expert – a grandmaster versus a random person on the street cannot identify a random chessboard any better than a regular person. If you just put chess pieces on the board at random. But if they’re party of a normal game, something he had studied, then it became the memory collection – recollection of how they recommended – what they recall about the chess board was greatly induced. The more you have known patterns in what you’re doing, the better recollection you have so the more production you’ll be. And I read a blog post a long time about how this applies to code standards. I can't find the blog post, but I think I found the study. So, if people are interested in in chess pattern recognition, here it is.

Alright! Andrew, what are your picks?

Got two picks today. The first one is a little article or poster – They’re both retro computing articles with somewhat of a Mac spin to them. The first one is an article about how the 'X' symbol – the 'X' icon became the symbol for close – for closing a window, that kind of thing in UI. And it has a nice little twist ending that I thought was fun, so read all the way to the end.

And then the other one is a blog post by Steve Troughton Smith who is an iOS developer that is all about how he's figured out how to build – he basically built an app that will run on – it’ll compile and run on Yosemite and will also compile and run on system 1.0 on a 1984 Mac. And it’s just interesting to see how much of that original Mac API is still available in the form of carbon in the newest version of OSX and how he actually – and then he actually ended up porting one of his apps that, I think, was an iOS app but he ported it to Mac OSX and will also run on classic on some really old version of the OS, so he goes through the technical details and stuff it’s pretty fun.

Those are my picks.

Alright. I just have one pick this week, and I'm going to give it a little context. Anyway, I've been playing a lot with YouTube lately as far as posting videos, and it’s pretty darn awesome. The little bit of context – I’ve actually been putting together some videos that I’m going to be posting soon, and I've been working on the remote conference that I put on for JavaScript developers which ends this week. So, if you're listening to this after we recorded it, you’re too late.

But, anyway it’s just really got a lot of tools to help you get you the word out and help other people. And so if you're looking for a way to contribute to the community, then by all means you know put together some screen recordings and just put it out there especially if you want to explain why you're doing anything like this. So those are my picks and David what are your picks?

Mine are going to seem so boring now because they’re all Swift related, but and I think I already mentioned them. But the first would be GitHub style guide was really interesting because they’re a Swift style guide. It’s interesting that it's very short and blunt. And as I mentioned I think it's interesting that they wrapped up the fact that – “Avoid inheritance.” That’s a part of their style guide. And I think probably everyone is interested already is in the Ray Wenderlich style guide but I thought GitHub’s was interesting.

And the other one, even though everyone, I’m sure already saw this and we talked about earlier but the release notes for Swift 1.2 really and Xcode 6.3. I think we should read that and get excited because of multiple if-lets on one line and also, hopefully, the beginning of the end of source kit service crashes as the mention of stability improvements in that area. So that one was huge for me. Those are my picks.

Alright! Well, thanks for coming, David.

Yeah! Thanks for having me! It was a lot of fun.

Alright. We will wrap the show up. I don't think we have any announcements we’ll catch you all next week.