I don't believe we should endorse a single blessed universal Swift style, which most users would feel obliged to adopt (even if they are not forced to). I would much prefer to establish a style sheet format that may be applied by Xcode or via the command-line, allowing different groups to automatically apply preferred formatting.
Code style supports an audience.There are many audiences out there, not a single monolithic one. Consider applying the typical stdlib style to the most trivial lesson code. Is this the kind of Swift we want to present to new users? It's unambiguously hideous for that purpose:
// Typical stdlib style
internal final override func _projectMutableAddress(
from base: UnsafePointer<Root>
) -> (pointer: UnsafeMutablePointer<Value>, owner: AnyObject?) {
// Since we're a ReferenceWritableKeyPath, we know we don't mutate the base
// in practice.
return _projectMutableAddress(from: base.pointee)
}
// Matching stdlib style
func greet(
name: String
) -> String {
return "Hello \(name)"
}
// Typical style for teaching
func greet(name: String) -> String {
return "Hello \(name)"
}
Wide tabbing, and simple declarations make it easier to present and grasp the core language. Short tabbing, limited line extent, line-based parameter declarations all support production values like easier diffs and code reading in printed form. This proposal assumes a uniform set of users, which is antithetical to the notion of a general purpose language.
While some parts of the language have developed community consensus as to their application, others have not. For example, using parentheses around functional closures and raw braces for procedural ones is a style with measurable benefit but minority adoption.
While no one will "force" anyone to use the standard Swift style, given the example of the switch
statement, there's no doubt that any given style choice will dominate. It's not worth fighting the editor or the standard format, regardless of how ugly the result. It's already bad enough trying to place the else
clause braces with guard
. Should we have to fight the tools to adopt the minority functional/procedural style just because it's not widely used by the arbiters of "standard"? What about those groups that use mandatory self
? Or mandatory internal binding? Standard style will exclude many kinds of well-considered safety choices and has the potential to incorporate unpopular ones.
Beyond trivial consensus like left-magnetic colons and commas, every single automatic styling decision is going to have to be fought in the public forum or decided by fiat. Neither outcome is a happy one. A standard style shouldn't be "everyone program like Google". We've seen bikeshedding and this has the potential to be the bikesheddiest bikeshedding ever. Plus the vast audience of users who do not participate in SE will have little say over the outcome. Compare this "Swift will adopt a standard style guideline" with SwiftLint, where adopted rules can be included or excluded by each house team.
To be successful, a Swift code style guideline sheet should be adaptive, and support multiple modalities appropriate to their audiences. The proposed toolset doesn't do that. SwiftLint does.
The proposal concerns are:
- Inconsistent style within projects: This is solved by linting.
- Code review focused on formatting issues: This is solved by linting.
- No "best practices" community consensus: I disagree that this does not already exist and is addressed by SwiftLint's default rule set.
- Cognitive burden of inconsistent community consensus: A consensus already exists across many projects for core styling choices but these choices are trivial.
Should the Swift language adopt a set of code style guidelines and a formatting tool?
I'd answer: "not as proposed", and certainly not without configurable rule-driven application of language formatters. Yes, let's have a linter and formatter but no, there is not one style sheet to rule them all and in the Swiftness bind them. Nor would it be healthy for the SE community to rigorously work through the minutia or good for the extended Swift User community to be compelled by (unenforceable) fiat to adopt them.