Conversation
|
We should discuss the addition of swift-format in a team meeting. I understand it is highly desirable for several contributors to have a tool enforcing code style automatically but I find many of swift-format's choices highly questionable and poorly interoperable with the way Xcode works. |
078f83a to
1a08ec1
Compare
|
Alright, you can check out the reformatting changes. Some of them I also don't think are improvements, so we can look into if we can fix them with customization options, and we can discuss how to proceed in the next meeting. |
|
How does Xcode work with regards to formatting? Doesn't it also use the toolchain's built-in swift-format? |
| else { | ||
| throw expected("annotation argument") | ||
| } |
There was a problem hiding this comment.
IMO the original version was fine.
| let members = | ||
| self.next(is: .leftBrace) | ||
| ? try parseTypeBody(in: &file, accepting: \.isValidStructMember) | ||
| : nil |
There was a problem hiding this comment.
IMO this is not an improvement
It can be set up with a post-build action. But I would not mind that much having to run some command in my terminal once in a while. My biggest complain is that Xcode has ways to automatically form certain things that swift-format will keep undoing. That is frustrating. On top of that, I personally prefer Xcode's styling over swift-format, which in places is IMO objectively worse (as you have noted in a few places). Here are a couple of things that I think are very annoying with swift-format. That's not an exhaustive list it covers the biggest issues I can think on top of my head:
let x = foo.bar(
a: something + that + is + very + long)
if let x = foo,
let y = bar
{ ham(x, y) }In addition, there are other things I have applied consistently throughout thousands of lines that swift-format is unable to enforce by itself, like adding spaces before and after the first and last member of a type declaration. |
Added a CI step to enforce formatting within the repository, and the scripts
format.shandlint.sh.