feat: Determine our SwiftFormat rules - WPB-10848

[samwyndham]

Issue

As discussed in Linting & Formatting Improvements (@johnxnguyen please take a look at that document as you were away during the meeting) we plan to improve our linting and formatting of Swift code to cover the entire codebase with more rules.

This PR is a place of discussion of SwiftFormat rules only. A similar PR will be created in the future to discuss SwiftLint rules. Once we have consensus on both SwiftFormat and SwiftLint rules we can move forward.

This PR will never be merged to develop.

Nearly every rule is enabled in this PR including the ones the make me 🤮 - there are two exceptions:

• acronyms as this is hard to use with coding keys.
• docComments as this won't work with our floating style comments.

Personally I'm of the opinion that generally the more rules the better that lead to a standard style across the team, but if we have preferences which these rules go against perhaps we can assert them via linting instead.

Task

Each commit (approximately) in this PR introduces a new rule to the codebase. The rule name will be in the title of the commit and there may be some additional info about it in the commit description.

As a reviewer your job is to go through the PR commit by commit and note down any rules that you dislike or have concerns about.

⚠️ Please leave you review here: https://wearezeta.atlassian.net/wiki/spaces/IOS/pages/1454800899/SwiftFormat+review

I will leave this PR up for some time. Please enjoy bike shedding.

Checklist

• Title contains a reference JIRA issue number like [WPB-XXX].
• Description is filled and free of optional paragraphs.
• Adds/updates automated tests.

[netbe]

docComments as this won't work with our floating style comments.
what do you mean by that?

[samwyndham]

docComments as this won't work with our floating style comments.
what do you mean by that?

@netbe I mean that we often have a line of whitespace between the doc comment and the declaration:

/// Adds two numbers

func add(a: Int, b: Int) {
  // ...
}

Whereas the rule expects the following and behaves incorrectly without it.

/// Adds two numbers
func add(a: Int, b: Int) {
  // ...
}

[samwyndham]

Here is my review of the rules. I am generally happy with most rules. I have reservations about the following:

• conditionalAssignment - I have mixed feelings about this one. I'm not super against it but feel that in some cases the content can become overly dense.
• preferForLoop - Mixed feelings. I would prefer if it ignored one liner forEach statements which can be done with --onelineforeach option.
• redundantType - This can be bad for compile times. If we do enable it we should also measure our compile times and add exceptions where necessary.
• markTypes - Creates a lot of marks and I don't feel they are that useful for anything. If everything becomes a mark what is the point.
• organizeDeclarations - Not against this, but I think this one requires a closer look and discussion. It moves our code around a lot.
• wrapConditionalBodies - I don't like this one as I like single line early exits.
• wrapSwitchCases - I don't like this one. It takes up unnecessary space in my opinion.