Kodeco Forums

Swift Style Guide: April 2016 Update

🎓 Courses & Articles
1

We've updated our popular Swift Style Guide for Swift 2.2 - check out the changes inside!

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1179-swift-style-guide-april-2016-update
2

I like

var names = [String]()

not

var names: [String] = []

3

Hi! The rationale behind the change is here: Reconsidering empty array and dictionary initialization · Issue #143 · raywenderlich/swift-style-guide · GitHub

There was a lot of support for it on twitter (unfortunately not documented here). If you feel strongly that it should change, feel free to re-open the issue and provide your rationale and why we should reconsider it.

You might just want to fork your own version of the style guide and make changes where you need. (In my own personal projects I adopt the RW style guide with some modifications and do exactly this.) It is hard to make a style that everybody loves. :slight_smile:

4

Honestly,

var names: [String] = []
var lookup: [String: Int] = [:]

Seems redundant, why use type inference everywhere but here? I understand specifying when the values are ambiguous, but this seems completely unjustified as a change. Personally, I’m totally not a fan.

Then there’s:
// Preferred
func computeFFT(context: Context?, inputData: InputData?) throws → Frequencies {

      guard let context = context else { throw FFTError.NoContext }
      guard let inputData = inputData else { throw FFTError.NoInputData }
     
      // use context and input to compute the frequencies
     
      return frequencies
    }

One of the worst things I see in bad coding habits consist of one liner check/returns. This should definitely be adjusted to:

  guard let context = context else { 
        throw FFTError.NoContext 
  }
  guard let inputData = inputData else { 
        throw FFTError.NoInputData 
  }

You guys might want to adjust your lazy loading examples as well. There are numerous situations where self is restricted in usage in lazy loading.

1 Like
5

Thanks for the feedback!

The relevant issue for array and dictionary initialization is Reconsidering empty array and dictionary initialization · Issue #143 · raywenderlich/swift-style-guide · GitHub

Also, it seems like Apple, and some other big publications have standardized on the [] and [:]

Example:

“var emptyDictionary: [String: Double] = [:]”
Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2.2).” iBooks. ‎The Swift Programming Language (Swift 5.7) on Apple Books

The RW guide is all about conserving print space which is probably why there were no objections to it during the review. I think an argument could be made that it easier to put a breakpoint when the throw gets its own line. I think it might be worth opening an issue and discussing as part of the next update! :sunny: :smile:

The reason your version isn’t compiling is that your view controller needs to adopt the CLLocationManagerDelegate protocol. Then it will compile without error.

6

My thoughts on the new changes (and some old ones).

  1. I’m not happy about Apple deprecating ++ and -- operators. These have been around for so long and in many languages. Programmers know what these mean. I honestly don’t see how swapping that with x += 1 improves readability. If anything it kind of reduces it.

  2. I followed almost everything from RW guidelines except for the 2 space tab. I understand that when you put code snippets in articles and books, real estate is not a luxury. But if you guys could at least keep it 4 space in the downloadable example books, that would be very appreciated. 2 space tabs just makes it all look condensed and crowded. It’s just not pretty or readable at all.

  3. I too had an internal conflict within me about var names: [String] = [] vs. var names = [String][] for the longest time. I liked the first method but over time I resorted to using the latter one. But I think I’ll make myself conform to the new recommended way. Since I always liked it as well.

  4. This is my biggest gripe with the new change by Apple. Lowercasing enum cases. For some reason I always preferred to have the enums stand out. This one is gonna be a bitter pill to swallow.

7

My bad regarding the delegate (It was a quick copy paste without reviewing). There are numerous scenarios I’ve run into when using self within a lazy load block in which self is evaluated as a function that returns an NSObject prior to being initialized. This leads into a ton of nuances. This is what I wanted to point out.

8

Great point about being careful using unowned vs. weak in capture lists, such as with network requests. Really, any situation when the capture can become nil before the closure is executed should use weak instead of unowned. I go into this a bit more in an article I wrote recently, in case anyone is interested: http://as.ync.io/capturing-reference-types/.

1 Like
9

Nice article! BTW, the reason why we went with strongSelf instead of `self` is because it is considered by some (including some members of the core team) to be a bug. :grimacing:

1 Like
10

Totally with you on the lowercase enums. There was a pretty significant anti-contingency on the evolution mailing list but I think that ship has sailed. :frowning:

11

Great guide for swift developer rayfix shared by you.

1 Like