What do you think of the following?
This code does a bunch of things that aren’t typical. First, all function params are single-lined and left-aligned including the first param. Second, the return token and the closing paren are on their own line. Third, the complex return ternary is split into 4 lines, with left-aligned ? and : cases.
I’m just messing with styling, there are no rules or principles here. Thoughts?
Update: Jessy suggests using combined lets for sequential assignments but I’m not really seeing the appeal here:
More examples in his gist.
11 Comments
There’s many things I like here – I don’t think I like how far left the parameters are because I can’t easily visually separate the function name from the signature from the body. If lines 4-8 were indented a bit, I think I’d like this better.
Daniel
Sorry – meant to add – then you could move the body back further left and not have to indent it so much.
The only rule here is that it has to be naturally indented by Xcode. Adding any spacing, tabbing, etc. is untenable long term for dev. So for example, no co-aligned param colons
I’d sooner stop coding than let Xcode format my code 🙂 Xcode isn’t nearly as bad with Swift as it is with Obj-C, but it is amazingly good at making Obj-C code into an unreadable mess imo. I’m a big Python fan, so it drives me nuts when Xcode chooses to do inconsistent things with whitespace (e.g.: making my “switch” cases flush with the “switch” keyword)
Not a fan. Makes me read more top to bottom instead of left to right
That’s why I like it. Left-to-right makes it easy to miss mistakes, especially in functions with many arguments, or ternary conditions. The latter are a breeze for a human to parse when each section has its own line. Also, if you split statements apart, you wind up with shorter line lengths, and the breaks between them add clarity instead of just happening arbitrarily depending on the width of your display, or your choice of “standard line-length.” If you go with 80 characters, you’ll be splitting lines pretty frequently in Cocoa anyways.
Here’s the way I do it, along with an elongated form to show why:
https://gist.github.com/Jessy-/b37f3e2bafeeeef3d25c
I updated the gist with an example of “combined lets” I’ve used. My style, which is based around the dependency of some lets upon others, is unfortunately not “naturally indented by Xcode”. I’m not okay with that but I will continue with it for the readability benefit I perceive.
I like it. It’s actually pretty close to how I code, which in a nutshell is: as *stylistically* verbose, and with as much whitespace as possible. I try to keep arguments one to a line (pressures me to use fewer of them); I use snake_case (longer, but less cryptic, and wastes less time reasoning about letter case); I break my ternary conditions onto 4 lines (way, way easier to follow the logic). Mind you, I generally have a bias toward the less popular of any two choices, so my choices might just be self-delusion. The advantage I find, when I’m having a good day, is that it pressures me to use as little code as possible, and I find my code easier to understand, if I’ve left it for a while. I should note, I would not use this style in groups, since my coworkers would kill me, and I might reconsider if I were stuck with a small display.
That’s how I would do it: https://gist.github.com/ilyannn/b0b9860c463a1013fc95
– shorter parameter names
– use internal parameter names
– more vertical spaces
– left-aligning parameters is the way to go
– computation becomes more logical if we also consider the “center” case
I usually structure ternarys in this way in objc (by surrounding the entire ternary expression in parens to make xcode auto-indent it for me), but I haven’t used ternarys much at all yet in swift. It makes it easier to scan to see exactly what values are returned in each case.
I don’t care for the return on its own line personally. If the expression being returned is short enough to read without much horizontal scanning then I prefer it to be on the same line as what it’s returning. In this example breaking up the ternary i feel is enough to satisfy that.
parameters on their own line seems nice, but it would be nicer if they were aligned by colon, similar to how xcode does that with objective-c (moot point though since it doesn’t now do so automatically).