Order of declarations in classes and structs about swift-style-guide HOT 7 CLOSED

👍

Especially once // MARK: (or whatever the Swift pragma mark looks like) starts getting picked up by Xcode to keep things organized conceptually.

from swift-style-guide.

I'm still not a fan of saying where anything goes. This guide is for tutorial/book writing. If I am editing your tutorial/chapter, and you instruct the user to put something someplace, and that "someplace" does not affect the code's execution, I will remove said instruction. There is no need for this.

--------- Original Message --------- Subject: [swift-style-guide] Order of declarations in classes and structs (#36)
From: "Matthijs Hollemans" [email protected]
Date: 6/27/14 5:20 am
To: "raywenderlich/swift-style-guide" [email protected]

The style guide currently says that public methods come before private methods. I am not a fan of that.
Things that are conceptually related should be close together, so if public method a() uses private methods b() and c(), then b and c should be near to a, not below all other public methods.
Of course, we don't know what sort of access controls will be added to Swift, but my vote is for keeping related methods together even if this means mixing "public" and "private".

Reply to this email directly or view it on GitHub.

from swift-style-guide.

+1 for functional organization of code.
I agree with @elephantronic that in the tutorial itself you shouldn't need to say what code goes where, but if readers download the final, completed project, there should be clear and consistent organization of code.

And so, I feel organization and readability should definitely be in the guide

from swift-style-guide.

That's a good point. I was thinking more starter projects and having those well-organized, but the same applies to the final downloadable projects too.

from swift-style-guide.

This also may or may not be true. For example, last year for iGT we threw out all the projects from all the authors. The projects that were included with the book were those that we built when we followed the instructions from the chapter during the FPE.

Also, different people organize things differently. Some people might want private properties at the bottom of a class to keep them out of the way. Others might put them inside a different structure that isn't even in the same file. You can say things should be well-organized, but you can't define what well-organized is.

Matthijs already gave a good example earlier -- some people want to have things grouped by logic, while other people want to group them by public/private.

As for me, I group them in the order I ask the reader to add them, because the chapter was organized in a logical way, and I want the reader to be able to compare their work to the projects easily. If you put things in different places than where the reader probably put them if they followed your instructions, your "organized" code will actually be harder to follow because it won't line up with what they tried to do. That makes finding differences more difficult.

--------- Original Message --------- Subject: Re: [swift-style-guide] Order of declarations in classes and structs (#36)
From: "Greg Heo" [email protected]
Date: 6/27/14 2:32 pm
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

That's a good point. I was thinking more starter projects and having those well-organized, but the same applies to the final downloadable projects too.

Reply to this email directly or view it on GitHub.

from swift-style-guide.

The projects that were included with the book were those that we built when we followed the instructions from the chapter during the FPE.

That's typically how my final project comes about as well. Most of my stuff has always included a starter project, which I keep organized/clean. But I always go through the tutorial/chapter and what comes out of that is what I end up submitting as the final project. It's a good sanity check rather than submitting what you came up with before you started writing.

from swift-style-guide.

I gotta go with Chris LP on this one - organizing code is nice for a real project, but I'm not sure it's the best thing for a tutorial workflow. I prefer not telling the reader where to put methods/variables unless necessary for functionality, and often like seeing final projects in order that the methods are added to the tutorial (for easy comparisons). It's a pretty subjective topic.

So my 2c - keep ordering issues out of the guide and leave it to the individual authors/editors.

from swift-style-guide.