-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guard statement styling #212
Comments
I like this suggestion.... modulo 2-space 4-space indentation :] |
Starting to have second thoughts about this one. I have seen a lot of swift code, from libraries authors that I really admire doing guards as one liners. Any thoughts @JRG-Developer @eskerber @jawwad @gregheo ? Possible compromise: show all of the examples using the above format but not legislate on it. |
Here are my thoughts:
My reasoning is that it's not typically critical to whatever the main purpose of the method is. Sure, it's definitely required to be there, but I don't think it's worthwhile to waste three lines on simple guards like this. This also helps to make text in print, web, etc a bit shorter, which is a plus.
The difference here is keeping the |
I borrowed the initial format from Apple but then I changed my code style too. It's reasonable to use a one-liner if you are returning instantly. Here is the new version: Single: guard let name = json["name"] as? String else { return nil } Multi: guard let name = json["name"] as? String,
let coordinatesJSON = json["coordinates"] as? [String: Double],
let latitude = coordinatesJSON["lat"],
let longitude = coordinatesJSON["lng"],
let mealsJSON = json["meals"] as? [String]
else { return nil } I think |
Having it on one line prevents you from putting a breakpoint on the failure case no? |
@rayfix yeap, you can't do that... ¯_(ツ)_/¯ |
I’ve tried and used both of these styles and my preference ended up being the one line option too. In my opinion, having more terse and readable code outweigh any disadvantage. I can see where people who disagree are coming from though. Other than problem @rayfix mentioned, I see two other downsides. Sometimes they end up being relatively long, hence making them less readable. (I'm sure I could find more extreme examples): Multiple lines:
One line:
The other problem is just consistency. I would never do a one line But again, my preference is still using one line. Just trying to turn a few more rocks. |
My inclination is that there is no hard and fast rule on this. Maybe we should be explicit about that the way we were with closure chaining.
|
I did an informal survey of some highly starred Swift libraries including the Swift Standard Library, Almofire, Unbox, SwiftyJSON, Spring. There is no real consensus that I can find. They all look pretty good to me in their own context. Even in the Apple JSON example from https://developer.apple.com/swift/blog/?id=37 they put the So I think I am falling into the camp of wanting to embrace the flexibility that the language allows. I think this favors readability (clarity) at the expense of some consistency. I could be wrong, but I don't want to hold the release on this issue. My goal is to have the document reviewed by the team on Monday so that it can be merged on Thursday. If you want to appeal I am totally cool with that! Please state your case (here) and I will forward it to the team leads to make a final decision. Regardless, I want to thank you for bringing up this issue as it has given me better clarity and sparked some useful discussion and insights. |
Hi,
I am seeing a lot of inconsistent
guard
statements. Can we add a section forguard
statements in styleguide?Suggesstion:
One statement:
Multi statement:
The text was updated successfully, but these errors were encountered: