profile
viewpoint
Cal Stephens calda iOS Engineer San Francisco, California https://calstephens.tech Building the future of travel @airbnb. Previously @apple, @mailchimp, @gatech.

calda/CGPathIntersection 23

:curly_loop: A CoreGraphics library that identifies points where two CGPaths intersect.

calda/Airline-Logos 16

Logos for most major world airlines & a downloader script

calda/Brainy-Phonics 10

🐦 An educational game that teaches basic reading skills and word recognition. Published by Augusta University.

calda/Blurb 7

:droplet: An iOS image editor that lets you create square images with blurry backgrounds

calda/Emoji-Names 6

:smile: An iOS app that reveals the unicode names of emoji

calda/Emoji-Sudoku 5

:watch: Sudoku app for watchOS and iOS

calda/AdaptiveFormSheet 4

:arrow_up: A Modal Presentation Controller that adapts to content size, keyboard visibility, and touch input.

calda/DeclarativeTableViewController 3

🏗 A simple, declarative approach to building Table Views in Swift. Define your cells and go.

calda/calstephens.tech 2

👨🏼‍💻 My personal website / blog / portfolio

calda/CodingKeyPath 2

Add support for Encoding and Decoding nested objects with dot notation (Prototype implementation for the Swift Standard Library)

push eventcalda/SwiftFormat

Cal Stephens

commit sha d0b99df7c650f1af2cd134bdaf3e9718eaaa97f1

Sort declarations in each category into subgroupings

view details

push time in an hour

push eventcalda/SwiftFormat

Cal Stephens

commit sha 430b260a18fa7efb876e5789c9ce3f6e2e1f29b5

Insert marks to separate categories

view details

push time in 8 hours

push eventcalda/SwiftFormat

Cal Stephens

commit sha e024d8aec53f324e0a2ebc1c474cc7dc659a9b6d

First pass ROUGH support for sorting by visibility (that actually works!!!)

view details

push time in a day

push eventcalda/SwiftFormat

Cal Stephens

commit sha d9b1c461b37331452f6e290f2efa6895dd370251

Handle free-floating comments separately from other declarations

view details

push time in a day

create barnchcalda/SwiftFormat

branch : cal--sort-declarations-by-visibility

created branch time in a day

issue commentnicklockwood/SwiftFormat

[Discussion] New file / type organization rules

Cool, thanks for your input! Great suggestions about potential customization options.

calda

comment created time in 8 days

issue openednicklockwood/SwiftFormat

[Discussion] New file / type organization rules

There are several rules related to file / type organization that I'd like to reintroduce to the Airbnb Swift Style guide:

Our policy is that we only include rules that can be formatted automatically (right now, either by SwiftFormat or SwiftLint).

Does these seem appropriate for a new SwiftFormat rule / set of rules?

  • These seem like they could be too niche / Airbnb-specific, so may not be worth supporting in SwiftFormat itself.
  • I'm not sure if SwiftFormat has good mechanisms for moving around entire blocks of code (since most of its rules work in terms of individual tokens in individual expressions).
  • If not added as a SwiftFormat rule, we could write our own file organization formatter (and use it alongside SwiftFormat).

Interested in hearing your thoughts on this!

created time in 8 days

push eventairbnb/swift

Cal Stephens

commit sha f8a3b217d7eb12fab01cbbb07aef8474ed5f7a68

Reintroduce old wrapping rules (#101)

view details

push time in 9 days

push eventcalda/airbnb-swift-style-guide

Cal Stephens

commit sha 5159d6861baa0a917314dd129d2190e055b3fa67

Reorganize

view details

Cal Stephens

commit sha dad4829d74cc593f9b3655f2972ea835d7b21f8d

Update examples

view details

push time in 9 days

Pull request review commentairbnb/swift

Reintroduce old wrapping rules

 _You can enable the following settings in Xcode by running [this script](resourc   ```    </details>+  +* <a id='long-function-declaration'></a>(<a href='#long-function-declaration'>link</a>) **Separate [long](https://github.com/airbnb/swift#column-width) function declarations with line breaks before each argument label and before the return signature.** Put the open curly brace on the next line so the first executable line doesn't look like it's another parameter. [![SwiftFormat: wrapArguments](https://img.shields.io/badge/SwiftFormat-wrapArguments-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#wrapArguments) [![SwiftFormat: wrapMultilineStatementBraces](https://img.shields.io/badge/SwiftFormat-wrapMultilineStatementBraces-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#wrapMultilineStatementBraces)

Oops! Good catch

calda

comment created time in 10 days

Pull request review commentairbnb/swift

Reintroduce old wrapping rules

 _You can enable the following settings in Xcode by running [this script](resourc   ```    </details>+  +* <a id='attributes-on-prev-line'></a>(<a href='#attributes-on-prev-line'>link</a>) **Place function/type attributes on the line above the declaration**. [![SwiftFormat: wrapAttributes](https://img.shields.io/badge/SwiftFormat-wrapAttributes-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#wrapAttributes)

Discussed on Slack -- keeping this here since it also applies to types.

calda

comment created time in 10 days

push eventcalda/airbnb-swift-style-guide

Cal Stephens

commit sha 57cb12234a048ea572d0cf2b49ddf27c475129b7

Reorganize

view details

push time in 10 days

push eventcalda/airbnb-swift-style-guide

Cal Stephens

commit sha f3ddbb9289294d47d29c6aa77d07d2321deaa54c

Fix wrapMultilineStatementBraces badge

view details

push time in 10 days

pull request commentairbnb/swift

Reintroduce old wrapping rules

  • Closes #38
  • Closes #40
  • Closes #42
  • Closes #46
calda

comment created time in 10 days

create barnchcalda/airbnb-swift-style-guide

branch : cal--wrap-rules

created branch time in 10 days

create barnchcalda/airbnb-swift-style-guide

branch : cal--long-function-invocation

created branch time in 10 days

issue commentnicklockwood/SwiftFormat

Unexpected behavior for indent rule

Awesome!! Super excited that we can bring back some of our old Style Guide rules now

calda

comment created time in 11 days

push eventairbnb/swift

Cal Stephens

commit sha 72f61ff57172048bbe07cdafb70075fbd4fcebfe

Patch use-anyobject markdown formatting (#100)

view details

push time in 17 days

delete branch airbnb/swift

delete branch : calda-patch-1

delete time in 17 days

PR merged airbnb/swift

Patch use-anyobject markdown formatting

It looks like we need an extra line of whitespace for GitHub to render this rule's markdown correctly.

+2 -1

0 comment

1 changed file

calda

pr closed time in 17 days

PR opened airbnb/swift

Patch use-anyobject markdown formatting

It looks like we need an extra line of whitespace for GitHub to render this rule's markdown correctly.

+2 -1

0 comment

1 changed file

pr created time in 17 days

create barnchairbnb/swift

branch : calda-patch-1

created branch time in 17 days

issue closedairbnb/swift

Prefer AnyObject over class in protocol definitions

This accepted Swift proposal that merges the concepts of class and AnyObject states that

we suggest only keeping AnyObject around

We should update the guide to align with this evolution of Swift.

Popular linters such as Swift format and Swift lint already have rules for this:

https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#anyobjectprotocol

https://github.com/realm/SwiftLint/tree/master/Source/SwiftLintFramework/Rules/Lint

closed time in 17 days

gsabran

issue commentairbnb/swift

Prefer AnyObject over class in protocol definitions

#99

gsabran

comment created time in 17 days

PR merged airbnb/swift

Prefer AnyObject over class in protocol definitions

Summary

https://github.com/airbnb/swift/issues/97

Use : AnyObject instead of : class in protocol definitions

Reasoning

This accepted Swift proposal that merges the concepts of class and AnyObject states that

we suggest only keeping AnyObject around

We should update the guide to align with this evolution of Swift.

Popular linters such as Swift format and Swift lint already have rules for this:

https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#anyobjectprotocol

https://github.com/realm/SwiftLint/tree/master/Source/SwiftLintFramework/Rules/Lint

Please react with 👍/👎 if you agree or disagree with this proposal.

+20 -1

1 comment

2 changed files

gsabran

pr closed time in 17 days

pull request commentairbnb/swift

Prefer AnyObject over class in protocol definitions

Thank you for your contribution @gsabran!

gsabran

comment created time in 17 days

push eventairbnb/swift

Guillaume Sabran

commit sha 55b47782d7fa634db82b2f49cf91b2f3ed782edc

Prefer AnyObject over class in protocol definitions (#99)

view details

push time in 17 days

push eventgsabran/swift

Cal Stephens

commit sha 5a2b726761ce22d15f2a0f4f2dfd9bc6a84dc21b

Update resources/swiftlint.yml

view details

push time in 17 days

Pull request review commentairbnb/swift

Prefer AnyObject over class in protocol definitions

 whitelist_rules:+  - anyobject_protocol

I don't think we need to update both swiftlint.yml and the airbnb.swiftformat. Since the rule links to the anyObjectProtocol SwiftFormat rule, I think we should just keep that one.

gsabran

comment created time in 17 days

pull request commentnicklockwood/SwiftFormat

Add rule for wrapping @ attributes on function and type declarations

I intended it to split them up into separate lines, but either seems reasonable since this is a fairly rare case.

calda

comment created time in 20 days

pull request commentairbnb/swift

Prefer AnyObject over class in protocol definitions

Looks like there's lots of support for this new rule!

@gsabran We can merge this once we update airbnb.swiftformat and add some additional rational to the rule body.

gsabran

comment created time in 20 days

Pull request review commentairbnb/swift

Prefer AnyObject over class in protocol definitions

 _You can enable the following settings in Xcode by running [this script](resourc      </details> +* <a id='use-anyobject'></a>(<a href='#use-anyobject'>link</a>) **Use `AnyObject` instead of `class` in protocol definitions.** [![SwiftFormat: anyObjectProtocol](https://img.shields.io/badge/SwiftFormat-anyObjectProtocol-7B0051.svg)](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#anyobjectprotocol)++  <details>+  

Perhaps:

  ### Why?
  
  [SE-0156](https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md]), which introduced support for using the `AnyObject` keyword as a protocol constraint, recommends preferring `AnyObject` over `class`:
  
  > This proposal merges the concepts of `class` and `AnyObject`, which now have the same meaning: they represent an existential for classes. To get rid of the duplication, we suggest only keeping `AnyObject` around. To reduce source-breakage to a minimum, `class` could be redefined as `typealias class = AnyObject` and give a deprecation warning on class for the first version of Swift this proposal is implemented in. Later, `class` could be removed in a subsequent version of Swift.
  
gsabran

comment created time in 20 days

pull request commentnicklockwood/SwiftFormat

Add rule for wrapping @ attributes on function and type declarations

It appears our rule only applies to functions and types. I'm not sure where we would land for properties.

calda

comment created time in 20 days

pull request commentnicklockwood/SwiftFormat

Add rule for wrapping @ attributes on function and type declarations

That makes sense as an additional option. I agree that many (or even most) people would prefer something like --attributewrap 10.

In the Airbnb Swift Style Guide specifically, our rule is that the attribute always goes on a separate like (even for short attributes @objc).

calda

comment created time in 20 days

PR opened nicklockwood/SwiftFormat

[iOS] Improve attributes rule with additional test cases

This PR fixes a few cases where the attributes rule added in #675 would accidentally wrap attributes associated with import and let/var declarations.

Before

@testable // this shouldn't have been wrapped
import Framework

@available(iOS 14.0, *)
class Foo {}
@IBOutlet // this shouldn't have been wrapped
var foo: UIView?

@available(iOS 14.0, *)
func foo() {}

After

@testable import Framework

@available(iOS 14.0, *)
class Foo {}
@IBOutlet var foo: UIView?

@available(iOS 14.0, *)
func foo() {}
+41 -5

0 comment

3 changed files

pr created time in 21 days

create barnchcalda/SwiftFormat

branch : cal--attributes-updates

created branch time in 21 days

pull request commentnicklockwood/SwiftFormat

Add rule for wrapping @ attributes on function and type declarations

Ran this on the regression suite and noticed a couple of issues -- will make a follow-up PR with a couple of improvements.

calda

comment created time in 21 days

push eventcalda/SwiftFormat

Nick Lockwood

commit sha b1bffbe05ea39b12d0353ab7d7e2f789f11be4f3

Double-indent trailing closure bodies when using --closingparen same-line (#667)

view details

Nick Lockwood

commit sha e00628af8243df6487b65f7a2cfea06533b7afab

Don't wrap brace when closing brace on same line

view details

Nick Lockwood

commit sha 88fe28dac3a89a8940895045ac1024c7a485d955

Remove deprecated methods

view details

Nick Lockwood

commit sha 8fd4e338777fa5d2037fc46ab7cfa4bf99fb5384

Fix rule ordering

view details

Nick Lockwood

commit sha 18b7c24bc234fa052a3c656bad6d8cc72946bc71

Delete commented code

view details

Nick Lockwood

commit sha 7435fb56e686374e9c786579ef634bb575d23f45

Improve closing scope indent logic

view details

Nick Lockwood

commit sha 66df0e850ce67c34d6201b17b6866ce03babb5d6

Improve guard else brace wrapping

view details

Nick Lockwood

commit sha eb9aac3a689508a04938682b140e6b64b33b0026

Handle multiline for loop brace wrapping

view details

Cal Stephens

commit sha 7d27b23ad130bd720dab1e36e06eee04e7dbdf73

Merge branch 'develop' into cal--attibutes-rule

view details

push time in 21 days

PR opened nicklockwood/SwiftFormat

Add rule for wrapping @ attributes on function and type declarations

This PR adds a rule for wrapping @ attributes (like @objc, @discardableResult, and @available).

It includes a configuration separate configuration points for function declarations (--funcattributes) and type declarations (--typeattributes). Both options are marked as preserve by default.

Examples

--funcattributes new-line

- @objc func foo() {}
+ @objc
+ func foo() { }

--funcattributes same-line

- @objc
- func foo() { }
+ @objc func foo() {}

--typeattributes new-line

- @objc class Foo {}
+ @objc
+ class Foo { }

--typeattributes same-line

- @objc
- enum Foo { }
+ @objc enun Foo {}
+296 -1

0 comment

8 changed files

pr created time in 21 days

PR closed nicklockwood/SwiftFormat

Don't orphan a guard statement's else keyword when formatting with wrapMultilineConditionalBraces

This PR updates the wrapMultilineConditionalBraces rule to never orphan guard statement's else keyword.

This code, formatted using --xcodeIndentation, is no longer reformatted when running wrapMultilineConditionalBraces:

guard self == .bar
     else {
         return ""
}

// Was previously being reformatted to:
guard self == .bar
     else 
{
         return ""
}
+129 -14

2 comments

4 changed files

calda

pr closed time in 21 days

pull request commentnicklockwood/SwiftFormat

Don't orphan a guard statement's else keyword when formatting with wrapMultilineConditionalBraces

All good, thanks for posting a fix :)

calda

comment created time in 21 days

push eventcalda/SwiftFormat

Cal Stephens

commit sha a25396cdabd5fef3a682a2aade160cc61c44eb6e

Add a new attributes rule

view details

push time in 21 days

create barnchcalda/SwiftFormat

branch : cal--attibutes-rule

created branch time in 21 days

PR opened nicklockwood/SwiftFormat

Don't orphan a guard statement's else keyword when formatting with wrapMultilineConditionalBraces

This PR updates the wrapMultilineConditionalBraces rule to never orphan guard statement's else keyword.

This code, formatted using --xcodeIndentation, is no longer reformatted when running wrapMultilineConditionalBraces:

guard self == .bar
     else {
         return ""
}

// Was previously being reformatted to:
guard self == .bar
     else 
{
         return ""
}
+27 -0

0 comment

4 changed files

pr created time in 21 days

pull request commentnicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

Aah interesting, I hadn't tried this with --xcodeindentation enabled. Patching this issue with a special-case sounds reasonable 👍

calda

comment created time in 21 days

pull request commentnicklockwood/SwiftFormat

Double-indent trailing closure bodies when using --closingparen same-line

I can make a follow-up PR that makes that the default, if you’d like.

calda

comment created time in 24 days

pull request commentnicklockwood/SwiftFormat

Double-indent trailing closure bodies when using --closingparen same-line

I don't think we have an explicit preference for that. Both seem fine to me personally (I'm not sure which I'd prefer if I had to pick one or the other)

calda

comment created time in 24 days

PR closed nicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

This PR adds a wrapMultilineStatementBraces rule, which was discussed briefly in #665

When the wrapMultilineStatementBraces rule is enabled, the opening brace for if / guard statements and func declarations will wrap to the next line. This is the style we use in the Airbnb Swift Style Guide.

  if foo,
-   bar {
    // ...
  }

  if foo,
+   bar
+ {
    // ...
  }
  guard foo,
-   bar else {
    // ...
  }

  guard foo,
+   bar else
+ {
    // ...
  }
  func foo(
    bar: Int,
-   baz: Int) {
    // ...
  }

  func foo(
    bar: Int,
+   baz: Int)
+ {
    // ...
  }
+597 -147

3 comments

31 changed files

calda

pr closed time in 24 days

pull request commentnicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

Ah I see that you fixed this in b9bad49, thanks!

calda

comment created time in 24 days

CommitCommentEvent

pull request commentnicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

@nicklockwood This PR reapplies #668 to develop instead of master 👍

calda

comment created time in 24 days

PR opened nicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

This PR adds a wrapMultilineStatementBraces rule, which was discussed briefly in #665

When the wrapMultilineStatementBraces rule is enabled, the opening brace for if / guard statements and func declarations will wrap to the next line. This is the style we use in the Airbnb Swift Style Guide.

  if foo,
-   bar {
    // ...
  }

  if foo,
+   bar
+ {
    // ...
  }
  guard foo,
-   bar else {
    // ...
  }

  guard foo,
+   bar else
+ {
    // ...
  }
  func foo(
    bar: Int,
-   baz: Int) {
    // ...
  }

  func foo(
    bar: Int,
+   baz: Int)
+ {
    // ...
  }
+520 -146

0 comment

31 changed files

pr created time in 24 days

create barnchcalda/SwiftFormat

branch : cal--wrapMultilineConditionalBraces-2

created branch time in 24 days

PR closed nicklockwood/SwiftFormat

Revert #668

Oops, #668 was accidentally merged into master instead of develop.

Let me put up a copy of #668 based on develop.

+0 -0

1 comment

0 changed file

calda

pr closed time in 24 days

PR opened nicklockwood/SwiftFormat

Revert #668

Oops, #668 was accidentally merged into master instead of develop.

Let me put up a copy of #668 based on develop.

+146 -520

0 comment

31 changed files

pr created time in 24 days

pull request commentnicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

Oh shoot great point, I bet this breaks #667. Let me add a test case that covers both at once to verify.

calda

comment created time in 24 days

push eventcalda/SwiftFormat

Cal Stephens

commit sha d48da6149def930607f29ebac216cfa69b3200da

Update example

view details

Cal Stephens

commit sha 96ae487703787407ee3d6d373ba9083a889a754e

Also apply to func decls

view details

Cal Stephens

commit sha eeb830b1149ecedb3aa3190f48a0ceb9cdd0bcdb

Update regression suite

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 1e6f3f09987e9c01ac05fde182132e133e686529

Update example

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 3fac3724a3b83b7682555ddfe45676f3305ab343

Update example

view details

push time in a month

PR opened nicklockwood/SwiftFormat

Add wrapMultilineConditionalBraces rule

This PR adds a wrapMultilineConditionalBraces rule, which was discussed briefly in #665

When the wrapMultilineConditionalBraces rule is enabled, the opening brace for if and guard statements will wrap to the next line. This is the style we use in the Airbnb Swift Style Guide.

// Before
if foo,
  bar {
  // ...
}

// After
if foo,
  bar 
{
  // ...
}
// Before
guard foo,
  bar else {
  // ...
}

// After
guard foo,
  bar else
{
  // ...
}
+429 -129

0 comment

30 changed files

pr created time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha d62c54e4cc95d826997bdbdd2cdd6108cfd9baea

Update the regression suite

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha ccda465753ee3a5f306fd8bbd4b6e82e6bc2416c

Add another test case

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha daf65efd22903c6fadf222f81e8724b6a3bc90a2

Reformat regression tests

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 9d994aced4acd384c573aa9f29489abbe2a6f895

Add another test case

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 1ebd1b77e7ec26d7758ff8cb304261476e47c231

fix type

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 675ef5ff4660d17705421e18f61b6364fd4f34ff

Reformat the regression suite

view details

push time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 523035070af515a60a41c49965fbfcbbd9414978

Add another test case

view details

push time in a month

create barnchcalda/SwiftFormat

branch : cal--wrapMultilineConditionalBraces

created branch time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 85572efbadeb7efd2a27aabac366bb94ac2f3c93

Add another test case

view details

push time in a month

push eventcalda/SwiftFormat

Nick Lockwood

commit sha 1271c39dd4f51b1393556ca27a36a6fb65b4e657

Minor refactoring

view details

Nick Lockwood

commit sha 4fb59098031c9666b73c372096db0992d51b040b

Fix indent for multiline string literal parameters

view details

Cal Stephens

commit sha 177821c06eeadd47db24f530061da6828773137c

Keep internal / external parameter labels on the same line (#666)

view details

Nick Lockwood

commit sha ecb98cb18d3bff802c4782ed51cca319a047846d

Simplified keepParameterLabelsOnSameLine logic

view details

Nick Lockwood

commit sha f16da0034a2e031d08be669f9ebe92a0a453aea4

Deprecate unused format function

view details

Nick Lockwood

commit sha 1f5a2e8f660944b63c45ed371d3e05e3780c384b

Don't override shared options with inferred value

view details

Nick Lockwood

commit sha 945ef1528ee9082dff721874ee142e0b15b7235e

Add inference for noSpaceOperators option

view details

Nick Lockwood

commit sha 3a131ff347e1c220251f4e315935684af821d3b8

Updated for 0.44.17 release

view details

Cal Stephens

commit sha f02e78ef4a6cc9a43cf37649630d8e186b593b2a

Merge branch 'develop' into cal--indent-closure-bodies

view details

push time in a month

PR opened nicklockwood/SwiftFormat

Double-indent trailing closure bodies when using --closingparen same-line

This PR updates the indent rule to double-indent trailing closure bodies when using --closingparen same-line.

This is now valid indentation when using indent --indent 2 --closingparen same-line:

self.method(
  withParameter: 1,
  otherParameter: 2) { [weak self] in
    guard let error = error else { return }
    print("and a trailing closure")
}

If you use --closingparen balanced (the default), the trailing closure body stays single-indented:

self.method(
  withParameter: 1,
  otherParameter: 2
) { [weak self] in
  guard let error = error else { return }
  print("and a trailing closure")
}
+64 -1

0 comment

3 changed files

pr created time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha 0bf6ddb8da7c96631fcc07b23bffd10df8dc7029

Add one more test case

view details

push time in a month

create barnchcalda/SwiftFormat

branch : cal--indent-closure-bodies

created branch time in a month

issue commentnicklockwood/SwiftFormat

Unexpected behavior for indent rule

This is how I would personally format multi-line if statements (and I'm fairly confident this would be our rule in the Airbnb Swift Style Guide):

if let foo = bar,
    let baz = quux 
{
    print("single-indented")
}

But I think we would prefer double-indenting trailing closure bodies (since this would match the indentation of non-trailing closure bodies):

self.method(
    withParameter: 1,
    otherParameter: 2) { [weak self] in
        guard let error = error else { return }
        print("and a trailing closure")
}

I think these two discussions are similar, but would be orthogonal configuration points (because we wouldn't want to use the same formatting behavior both of these cases).

calda

comment created time in a month

issue closednicklockwood/SwiftFormat

Unexpected indentation behavior for wrapArguments rule

I'm looking into adding the wrapArguments rule to the Airbnb Swift Style Guide.

This would allow us to bring back a few former style rules:

When we run swiftformat . --rules wrapArguments --wraparguments before-first --closingparen same-line on the following code, it's reformatted with unexpected indentation:

// Before
func constrainToParent(_
  attr1: NSLayoutConstraint.Attribute, times
  multiplier: CGFloat = 1, plus
  constant: CGFloat = 0,
  priority: UILayoutPriority = .required) -> NSLayoutConstraint
{

}

// After running `swiftformat . --rules wrapArguments --wraparguments before-first --closingparen same-line`
func constrainToParent(_
  attr1: NSLayoutConstraint.Attribute, times
  multiplier: CGFloat = 1, plus
  constant: CGFloat = 0,
                       priority: UILayoutPriority = .required) -> NSLayoutConstraint // Funky!
{

}

This is an old style that I don't see very often, but it would be great if SwiftFormat could reformat it to:

func constrainToParent(
  _ attr1: NSLayoutConstraint.Attribute, 
  times multiplier: CGFloat = 1, 
  plus constant: CGFloat = 0,
  priority: UILayoutPriority = .required) -> NSLayoutConstraint
{

}

closed time in a month

calda

push eventcalda/SwiftFormat

Cal Stephens

commit sha 53c8889228d48269ff53291a13a57d3c215d633b

Also add support for afterFirst

view details

push time in a month

pull request commentnicklockwood/SwiftFormat

Keep internal / external parameter labels on the same line

Let me also add this to ‘afterFirst’, which will fix the specific behavior demonstrated in #664

calda

comment created time in a month

PR opened nicklockwood/SwiftFormat

Keep internal / external parameter labels on the same line

This PR updates the wrapArguments rule to make sure internal and external parameter labels stay on the same line.

  • This is an enhancement related to #664

Example:

// Before
func foo(with
    bar: Int, and
    baz: String
) -> LongReturnType {}

// After formatting with `wrapArguments`
func foo(
    with bar: Int,
    and baz: String
) -> LongReturnType {}
+49 -0

0 comment

3 changed files

pr created time in a month

push eventcalda/SwiftFormat

Cal Stephens

commit sha dece48b241e93249a3c28992d023830a4f7cae5d

Make the regression suite pass

view details

push time in a month

create barnchcalda/SwiftFormat

branch : cal--reunite-split-argument-labels

created branch time in a month

fork calda/SwiftFormat

A command-line tool and Xcode Extension for formatting Swift code

fork in a month

issue commentnicklockwood/SwiftFormat

Unexpected indentation behavior for wrapArguments rule

Here's another example:

// Before
func method(with
  parameter: Int,
  secondParemeter: Int)
{
  
}

// After running `swiftformat . --rules wrapArguments --wraparguments before-first --closingparen same-line`
func method(with
  parameter: Int,
            secondParemeter: Int) // Funky!
{
  
}
calda

comment created time in a month

issue commentnicklockwood/SwiftFormat

Unexpected behavior for indent rule

I see -- we'd like to use --closingparen same-line for wrapArguments, so I'm not sure if that suggestion would work for us.

Do you think it would be reasonable for us to contribute an option for this (like --closurebody indent)?

calda

comment created time in a month

issue openednicklockwood/SwiftFormat

Unexpected behavior for indent rule

I'm looking into adopting the indent rule in the Airbnb Swift Style Guide. We have an indentation rule (e.g. "Use 2 spaces to indent lines.") that is not currently being enforced with a SwiftFormat rule.

I'm seeing unexpected indentation behavior when I run swiftformat . --rules indent --indent 2:

// Before
self.method(
  withParameter: 1,
  otherParameter: 2) { [weak self] in
    guard let error = error else { return }
    print("and a trailing closure")
}

// After running `swiftformat . --rules indent --indent 2`
self.method(
  withParameter: 1,
  otherParameter: 2) { [weak self] in
  guard let error = error else { return } // I feel like the closure body should stay indented
  print("and a trailing closure")
}

Is this expected behavior of the indent rule, or is this a bug?

created time in a month

issue openednicklockwood/SwiftFormat

Unexpected indentation behavior for wrapArguments rule

I'm looking into adding the wrapArguments rule to the Airbnb Swift Style Guide.

This would allow us to bring back a few former style rules:

When we run swiftformat . --rules wrapArguments --wraparguments before-first --closingparen same-line on the following code, it's reformatted with unexpected indentation:

// Before
func constrainToParent(_
  attr1: NSLayoutConstraint.Attribute, times
  multiplier: CGFloat = 1, plus
  constant: CGFloat = 0,
  priority: UILayoutPriority = .required) -> NSLayoutConstraint
{

}

// After running `swiftformat . --rules wrapArguments --wraparguments before-first --closingparen same-line`
func constrainToParent(_
  attr1: NSLayoutConstraint.Attribute, times
  multiplier: CGFloat = 1, plus
  constant: CGFloat = 0,
                       priority: UILayoutPriority = .required) -> NSLayoutConstraint // Funky!
{

}

This is an old style that I don't see very often, but it would be great if SwiftFormat could reformat it to:

func constrainToParent(
  _ attr1: NSLayoutConstraint.Attribute, 
  times multiplier: CGFloat = 1, 
  plus constant: CGFloat = 0,
  priority: UILayoutPriority = .required) -> NSLayoutConstraint
{

}

created time in a month

issue commentairbnb/swift

Long function invocations should also break on each argument

It looks like SwiftFormat's --wraparguments before-first rule may work here

fdiaz

comment created time in a month

issue commentairbnb/swift

Multi-line arrays should have each bracket on a separate line

It looks like SwiftFormat's wrapArguments --wrapcollections before-first may work here

fdiaz

comment created time in a month

issue closedairbnb/swift

Discourage `none` case in enums

Consider the following contrived example:

enum RhymingWord: String {
  case cone
  case done
  case gone
  case none
  case zone
}

func rhymingWord(_ userInput: String) -> RhymingWord? {
  switch userInput {
  case "c": return .cone
  case "d": return .done
  case "g": return .gone
  case "n": return .none
  case "z": return .zone
  default: return nil
  }
}

assert(rhymingWord("c") == RhymingWord.cone) // passes
assert(rhymingWord("n") == RhymingWord.none) // fails

At first glance, it's not obvious why the first assertion passed but the second failed.

Expressions such as .cone are automatically converted to their expanded form (e.g. RhymingWord.cone) by the compiler. With all values expanded, the snippet becomes:

  switch userInput {
  case "c": return RhymingWord.cone
  case "d": return RhymingWord.done
  case "g": return RhymingWord.gone
  case "n": return Optional.none
  case "z": return RhymingWord.zone
  default: return Optional.none
  }

It's now obvious as to why the assertion is failing: Any optional enum set to .none will expand to Optional.none as opposed to its other none cases (e.g. RhymingWord.none in this case). This can lead to difficult to debug errors in code.

Proposal:

  • Never allow none as a case in an enum.

Alternatives considered:

  • Prevent any enum with the none case as being optional. (E.g. force all consumers to use RhymingWord instead of RhymingWord? because it already has a none representation.) Producers have no control as to how someone uses their data type (nor should they). Consumers should always be able to use a data type as an optional if it makes sense.
  • Always fully qualify the .none case in enums. (E.g. use case "n": return RhymingWord.none above.) This will be hard for consumers to remember to fully qualify only these specific cases.

closed time in a month

swift-ortal

push eventcalda/DuolingoAudioStories

Cal Stephens

commit sha 00677fad1b28d12c45692cd0c7f276350c0be71e

Update CSS classes

view details

push time in 2 months

push eventcalda/DuolingoAudioStories

Cal Stephens

commit sha 886d1118c65e79375bc0321a6d15c7aaa0c313b9

Update CSS classes

view details

push time in 2 months

push eventcalda/DuolingoAudioStories

Cal Stephens

commit sha e50977841a12e616870fee896883387285980565

Update CSS classes

view details

push time in 2 months

push eventcalda/DuolingoAudioStories

Cal Stephens

commit sha 07c9760815533e4ac8b876cca5b3979f204eb099

Update CSS classes

view details

push time in 2 months

push eventcalda/DuolingoAudioStories

Cal Stephens

commit sha 0a61ce58feb0a1971b5f5bce3efcebaa56037950

Update CSS classes

view details

push time in 2 months

more