The Ray Wenderlich style guide contains *some* useful insights, but you should not take it as a “swift best practices” guide, or even a good code style guide for your own projects. At the risk of sounding blunt, the RW style guide is optimized for blog posts and cheap tutorials, not a cohesive Swift code base you have to maintain over time. In addition that website is heavily iOS-developer oriented, and the iOS platform forces you to interact with a lot of Objective C frameworks which are more reference-oriented than native Swift code should be.
Enum scoping is when you want to group free floating functions into a common namespace to avoid polluting the global scope. For example one of the libraries I maintain has a collection of internal math functions which are handy to have around. enum Math { typealias IntV2 = (a:Int, b:Int) typealias IntV3 = (a:Int, b:Int, c:Int) typealias DoubleV2 = (x:Double, y:Double) typealias DoubleV3 = (x:Double, y:Double, z:Double) @inline(__always) private static func fraction(_ x:Double) -> (Int, Double) { let integer:Int = x > 0 ? Int(x) : Int(x) - 1 return (integer, x - Double(integer)) } @inline(__always) static func fraction(_ v:DoubleV2) -> (IntV2, DoubleV2) { let (i1, f1):(Int, Double) = Math.fraction(v.0), (i2, f2):(Int, Double) = Math.fraction(v.1) return ((i1, i2), (f1, f2)) } @inline(__always) static func fraction(_ v:DoubleV3) -> (IntV3, DoubleV3) { let (i1, f1):(Int, Double) = Math.fraction(v.0), (i2, f2):(Int, Double) = Math.fraction(v.1), (i3, f3):(Int, Double) = Math.fraction(v.2) return ((i1, i2, i3), (f1, f2, f3)) } @inline(__always) static func add(_ v1:IntV2, _ v2:IntV2) -> IntV2 { return (v1.a + v2.a, v1.b + v2.b) } ... } Some, but not all projects will end up with a `Constants`, enum to store global constants too. Beyond that, you shouldn’t be Enum scoping a lot, it usually isn’t hard to find a real type where some method or constant belongs. That being said, you can find a few examples of this pattern in the Swift standard library: `Unicode`, `CommandLine` and `MemoryLayout` come to mind. On Fri, Jun 30, 2017 at 12:12 AM, Vitor Navarro via swift-users < swift-users@swift.org> wrote: > Hi Alex, > > Thank you for the reply, actually Taylor gave me a great answer which > solved my question, that was "struct or classes and when should we apply > each". > > Regarding the reference I found this https://github.com/ > raywenderlich/swift-style-guide#code-organization which doesn't follow > exactly the structs most of the times approach or the protocol driven > development (WWDC) > > Again thanks. > > 2017-06-29 14:21 GMT-04:00 Alex Blewitt <alb...@apple.com>: > >> On 29 Jun 2017, at 18:16, Vitor Navarro via swift-users < >> swift-users@swift.org> wrote: >> >> Hi, >> >> I know this question is probably done a thousand times, but I wanted to >> hear from Swift dev community. >> >> >> What is the question? >> >> I think both of them have right places for usage depending on the >> occasion but documentation, WWDC and the internet give opposite answers >> regarding this. >> >> >> Do you have references that you can share? >> >> Do you guys have any guideline regarding usage here? >> >> >> The Swift Programming Language sums up the similarities and differences >> between classes and structures quite well: >> >> https://developer.apple.com/library/content/documentation/Sw >> ift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html >> >> Alex >> >> > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users