Add a swift-format configuration file #9005
Conversation
bkhouri
requested review from
jakepetroules,
dschaefer2,
shawnhyam,
bripeticca,
plemarquand,
owenv,
cmcgee1024 and
daveyc123
as code owners
|
@swift-ci test |
| "indentation": { | ||
| "spaces": 4 | ||
| }, | ||
| "lineBreakBeforeEachArgument": true, |
There was a problem hiding this comment.
This rule feels a little too opinionated to me, not sure if anyone else has an opinion
There was a problem hiding this comment.
I think this option helps make the diff ever-so-slightly cleaner to read.
There was a problem hiding this comment.
This would result in a pretty huge diff. While I agree it can enhance readability in some cases, I'm not sure we should make the jump right away. I'd omit this for now and maybe we should have a wider discussion first.
There was a problem hiding this comment.
I would like to get to the following
func foo(a: Int, b: String) {
}
to
func foo(
a: Int,
b: String,
) {
}
| { | ||
| "version": 1, | ||
| "lineLength": 10000, | ||
| "indentation": { |
There was a problem hiding this comment.
suggestion: I haven't read the documentation, but based on the setting name, we should consider "multiElementCollectionTrailingCommas" : true,.
There was a problem hiding this comment.
That corresponds to:
[
"a",
"b"
]vs
[
"a",
"b",
]Support for the latter was added to Swift some time ago, the argument being that it helps reduce the SCM diff as new lines are added to the bottom.
I'd be fine with enabling that rule.
There was a problem hiding this comment.
I want the latter :)
There was a problem hiding this comment.
I also want
[1, 3]
to format to
[
1,
3,
]
| }, | ||
| "lineBreakBeforeEachArgument": true, | ||
| "rules": { | ||
| }, |
There was a problem hiding this comment.
suggestion: I haven't read the documentation ,but based on the setting name, we should consider the following, eventually:
"rules" : {
"AllPublicDeclarationsHaveDocumentation" : false,
}
There was a problem hiding this comment.
Good to strive towards, but we should not add that immediately as I think for SwiftPM in particular there's a lot which is public but which maybe shouldn't be.
There was a problem hiding this comment.
100% agree :). Something to consider for the future.
| { | ||
| "version": 1, | ||
| "lineLength": 10000, | ||
| "indentation": { |
There was a problem hiding this comment.
That corresponds to:
[
"a",
"b"
]vs
[
"a",
"b",
]Support for the latter was added to Swift some time ago, the argument being that it helps reduce the SCM diff as new lines are added to the bottom.
I'd be fine with enabling that rule.
| @@ -0,0 +1,11 @@ | |||
| { | |||
| "version": 1, | |||
| "lineLength": 10000, | |||
There was a problem hiding this comment.
Agree with this; we should not enforce a line length.
| "indentation": { | ||
| "spaces": 4 | ||
| }, | ||
| "lineBreakBeforeEachArgument": true, |
There was a problem hiding this comment.
This would result in a pretty huge diff. While I agree it can enhance readability in some cases, I'm not sure we should make the jump right away. I'd omit this for now and maybe we should have a wider discussion first.
| }, | ||
| "lineBreakBeforeEachArgument": true, | ||
| "rules": { | ||
| }, |
There was a problem hiding this comment.
Good to strive towards, but we should not add that immediately as I think for SwiftPM in particular there's a lot which is public but which maybe shouldn't be.
|
@bkhouri Can you open a similar PR for swift-build? |
@jakepetroules there is already a Maybe we should merge this change once we have GitHub actions, where, in one PR, we enforce formatting rules and format the code base. |
No description provided.