Is there a way to enforce Allman bracing in closures AND functions/classes/structs?

[ZoeESummers]

I would very much like to ask for a rule / set of rules that force Allman braces on every pair of {} including closures and 'one liners'.

I thank you for taking a look at the extensive and I would argue complete set of rules and code formatting built into App Code, as discussed in another issue, and to that I would ask that for our little team, we like / prefer that everything is in Allman even 'one liners'.

Add to that we have. a specific layout of closures (using the long format in all cases) e.g.

1.    let dwarvesAfterM = arrayOfDwarfArrays.flatMap 
2.    { 
3.        array -> [String] in
4.            return array.filter
5.            { 
6.               dwarf -> Bool in
7.                   dwarf > "M"
8.            }
9.    }

where you can see 'in' becomes a brace type rule itself.

Do you think there is any hope your application could help?

[nicklockwood]

@ZoeESummers this is slightly improved in version 0.45.0. Allman indenting is now enforced for closures, however the arguments are not auto-wrapped onto the next line, and the in is not yet treated as a new scope.

[ZoeESummers]

Thank you! xXx Stay safe. Regards Zoe

…

On 30 Jul 2020, at 23:23, Nick Lockwood ***@***.***> wrote: @ZoeESummers <https://github.com/ZoeESummers> this is slightly improved in version 0.45.0. Allman indenting is now enforced for closures, however the arguments are not auto-wrapped onto the next line, and the in is not yet treated as a new scope. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAT7XPNM4BSWQV2SUSMJDJTR6HXHBANCNFSM4HDXJDJA>.

[altagir]

Allman indenting is now enforced for closure
@nicklockwood

I found this new behavior perturbating

the allman setting enabled creates lots of issue with Observable

it creates weird formatting now we used to fix manually

someObservable
     .switchMap { $0.syncDone }
     .switchMap
{ _ -> Observable<Int> in

when a "in" is present, allman should not be enforced to have proper alignment

[nicklockwood]

@altagir from what you've pasted, it seems that the problem is not that --allman shouldn't be applied when in is present, but rather than the brace should be indented to match the previous line (which looks like a bug rather than a deliberate design choice on my part). I would expect this to be formatted as:

someObservable
    .switchMap { $0.syncDone }
    .switchMap
    { _ -> Observable<Int> in
        ...
    }

[altagir]

@nicklockwood
it seems to appear on first block only

	        return SessionManager
				.shared
				.validateSession()
				.switchMap
		  	 { _ -> Observable<SomeEntity> in
                              someCode()
                         }
                         .switchMap
                         {
                         }

is there some options I specified which creates that ?

before latest version, I used to put the "param in" on same line as {
fixed the rest of alignments, but now is enforced to put block as allman, thus creating havoc in a general swiftformat .

thanks

[nicklockwood]

@altagir I'm pretty sure it's a bug, not something you did. I'll investigate.

[altagir]

@nicklockwood
I just tried the develop branch but issue remains

                     SomeManager
			.refresh()
			.switchMap
		{
			something()
		}
		.switchMap
		{
			$0.something
		}

[nicklockwood]

@altagir did you build the CLI from source, or just run the binary in the develop branch? The binary hasn't been updated.

[nicklockwood]

@altagir Oh wait, it seems there is still an issue. The code I tested was

func foo()
{
    return SessionManager
        .shared
        .validateSession()
        .switchMap
        { _ -> Observable<SomeEntity> in
            someCode()
        }
        .switchMap
        {
            otherCode()
        }
}

Which formats correctly. But if you remove the outer function it seems to be treated differently. I'd assume that doesn't arise very often in real (non-example) code, but I'll fix it anyway. Thanks for flagging it.

[altagir]

@altagir did you build the CLI from source, or just run the binary in the develop branch? The binary hasn't been updated.

I did build from source
Thanks for investigating ! :)

[ZoeESummers]

Thanks for the work Nick.

Do you know if this all works correctly in SwiftUI with its awful syntax?

[nicklockwood]

Do you know if this all works correctly in SwiftUI with its awful syntax?

Good question. I've done some testing with SwiftUI, but not with SwiftUI + Allman-style. I'll make sure to add some more tests around that. If you have any samples to share that would be helpful.

[altagir]

@nicklockwood
Hi I am still seeing the issue with latest code in develop

this is my config

--allman true
--specifierorder static,fileprivate,public,private,internal,open,required,convenience,weak,override,class
--binarygrouping 4,8
--closingparen balanced
--commas inline
--comments indent
--conflictmarkers reject
--decimalgrouping 3,6
--elseposition next-line
--guardelse same-line
--empty void
--exponentcase lowercase
--exponentgrouping disabled
--fractiongrouping disabled
--fragment false
--hexgrouping 4,8
--hexliteralcase uppercase
--ifdef outdent
--importgrouping alphabetized
--indent tab
--indentcase true
--linebreaks crlf
--octalgrouping 4,8
--operatorfunc spaced
--patternlet hoist
--ranges spaced
--self remove
--selfrequired
--semicolons inline
--stripunusedargs closure-only
--trailingclosures
--trimwhitespace always
--wraparguments disabled
--wrapcollections preserve
--wrapelements disabled
--xcodeindentation disabled
--exclude Pods,Generated,ThirdParty,Logs,Cpp,API,Tools
--disable andOperator,blankLinesAtStartOfScope,redundantExtensionACL,redundantGet,redundantNilInit,redundantObjc,redundantParens,trailingClosures,specifiers
--tabwidth 4

[nicklockwood]

@altagir that's very strange. I have that exact example in the Snapshots/Issues/406.swift file and it's working correctly (even if I include all options you've specified). Is there any other code in the file? Or perhaps some other configuration you are setting that might be relevant?

[nicklockwood]

@altagir maybe try running it again with --cache clear ?

[altagir]

@nicklockwood
Just tried with empty dir and the code above....

still same result :/

even without config file (not allman)
the first switchmap is badly indexed

[nicklockwood]

@altagir and with --cache clear?

[altagir]

@nicklockwood
yes even with swiftformat . --cache clear

[nicklockwood]

@altagir and you definitely checked out the develop branch, not master?

[altagir]

definitely :)

[nicklockwood]

@altagir unfortunately I can't find any explanation for this. There must be some difference with how you are running it, but I can't imagine what it could be.

[nicklockwood]

@altagir is this working correctly for you in the released version 0.45.4?

[altagir]

@nicklockwood
Hi Nick, I tried on a new machine (VM) and it worked with latest code ! Thanks!!

I see a weird thing though with other calls... like Async.main

[nicklockwood]

Hmm, I probably need to special-case this for Allman style. I'll fix that in the next version.

[nicklockwood]

@altagir fixed in 0.45.6.

[altagir]

@nicklockwood
I tested the main repo, and issue seems fixed, huge thanks ! :D