Class structure/organization about swift-style-guide HOT 10 CLOSED

Access control mechanisms (public/private/protected) are indeed coming. In addition, Xcode will have support for #pragma in the form of something like // MARK: <title>. Can't find the source on that, but was said by someone from Apple.

Supposedly, all of this is coming before the final release of iOS 8. I suggest that until then, we group everything using this:

/************************    Private    ************************/

Separate sections for public, private, overrides, delegate methods, IBAction methods, and anything you see fit on a case-by-case basis.

If they do introduce this new #pragma syntax, it should be pretty easy to find and replace with a regular expression.

from swift-style-guide.

It is indeed confirmed on the Apple Dev Forums that //MARK: and Access Control is coming. I hope that we get to use those soon.

Another thing we should definitely consider is the placement of class extensions and protocols.

It seems that Swift loves class extensions and protocols and the top of our files will likely be littered with them.

from swift-style-guide.

On the other hand, having to use #pragma mark is a sign that your class is too big and needs to be split up into several different classes instead.

from swift-style-guide.

I agree with Scott, with the lack of header files it is my opinion that all public properties and classes be at the top of the class and private ones sectioned off after all of the public ones. This way anyone consuming your class won't miss a public function in between two private ones. Has anyone heard about documentation in Swift? Maybe we will be able to create AppleDoc for our public stuff?

from swift-style-guide.

All good news!

@hollance I don't necessarily agree. It might be a smell, but sometimes you're just implementing the necessary stuff and want to keep things organized & consistent. For instance, I might have a VC that is 100 lines, but I'd still like to organize it the same as a VC that is 500 lines.

@cwagdev I haven't heard or seen anything about documentation yet.

from swift-style-guide.

@cwagdev The header doc type comments seem to work just fine in Swift, at least they work in Xcode when you Option+Click on something, and in the Quick Help inspector.

from swift-style-guide.

As far as class structure goes, I'm mixed on it. I like things structured nicely when I'm writing them myself, but I find that when writing/editing tutorials, I prefer to eliminate any notion of where to put things when it doesn't matter. So I'll say to add a method to a class, but I won't say "under such-and-such method" because the compiler doesn't care where in the class you put it, so we shouldn't distract the reader by making them try to find where to put it. Worse yet, we run the risk of inadvertently teaching readers that the position of something does matter when it doesn't. It just adds complexity.

However, when reading the finished file, it does look nicer when things have some organization.

--------- Original Message --------- Subject: Re: [swift-style-guide] Class structure/organization (#9)
From: "Matthijs Hollemans" [email protected]
Date: 6/10/14 12:42 pm
To: "raywenderlich/swift-style-guide" [email protected]

On the other hand, having to use #pragma mark is a sign that your class is too big and needs to be split up into several different classes instead.

Reply to this email directly or view it on GitHub.

from swift-style-guide.

@elephantronic excellent point when it comes to tutorial writing, no sense in confusing the reader with function positioning.

If this guide is specifically for tutorial writing than I would say it's not important to mention, if we're trying to set an industry standard then I would say it is.

from swift-style-guide.

Daydreaming:

Smalltalk, on which Objective-C was based, has the notion of categories. This is somewhat similar to Obj-C categories, but it's more like a "tag" that you give a method. The Smalltalk Browser then showed the methods organized by categories.

Other languages can use annotations to add arbitrary runtime data to methods etc. Maybe Swift will allow such annotations at some point, and might let you tag a method to put it inside a category.

from swift-style-guide.

Yeah, our original intention with these guides was to create them for the authors so our books and web tutorials would be consistent. One primary goal is readability when in print, so whitespace will come into play in our guides more than when coding in general.

I don't know if we should aim to set the industry standard, but mostly, I'm against anyone trying to do that.

--------- Original Message --------- Subject: Re: [swift-style-guide] Class structure/organization (#9)
From: "Chris Wagner" [email protected]
Date: 6/10/14 1:35 pm
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

@elephantronic excellent point when it comes to tutorial writing, no sense in confusing the reader with function positioning.
If this guide is specifically for tutorial writing than I would say it's not important to mention, if we're trying to set an industry standard then I would say it is.

Reply to this email directly or view it on GitHub.

from swift-style-guide.