-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
"Attributes should be on their own line" rule #846
Comments
👍🏻 this seems useful. For 3 we also put those on their own line. But that's just us! |
I've started looking into this, but I'm having trouble because the AST doesn't expose the range for the attribute:
I can get it from
How bad would be checking if it starts with |
It might be worth looking into how the valid documentation comment stuff works. As we don't get the offset for the comment either, but still access it. FWIW we have a rule for |
From what I've seen, the documentation rules use regex. I've opened #847 with my approach. |
FWIW, Erica Sadun did a quick poll around styling of attributes: http://ericasadun.com/2016/10/02/quick-style-survey/ |
Thanks for sharing! I've based my opinions on what I've seen in then Apple docs, although I forgot that you can use |
I think we should have a rule that some (that's the tricky) part attributes should be on their own line.
The attributes that I'd like to see in that list are:
@discardableResult
@available
@NSApplicationMain
@UIApplicationMain
@IBDesignable
The attributes that I particularly use on the same line:
@GKInspectable
@objc
@nonobjc
@NSCopying
@NSManaged
@testable
@IBAction
@IBOutlet
@IBInspectable
It seems to me that all the attributes that I use on the same line are in these categories:
var
import
@objc
or@nonobj
I'd be OK with
@objc
and@nonobj
being on their own line for functions/types but I don't think we can just use the "where is this attribute" rule because of@available
.The text was updated successfully, but these errors were encountered: