Vscode-powershell: formatting should allow brace indent to match contained code indent

[LeeDailey]

System Details

• Operating system name and version: win7x64
• VS Code version: 1.8.2
• PowerShell extension version: 0.9.0
• Output from $PSVersionTable:

Name                           Value                                           
----                           -----                                           
PSVersion                      5.1.14409.1005                                  
PSEdition                      Desktop                                         
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                         
BuildVersion                   10.0.14409.1005                                 
CLRVersion                     4.0.30319.42000                                 
WSManStackVersion              3.0                                             
PSRemotingProtocolVersion      2.3                                             
SerializationVersion           1.1.0.1   

Issue Description

howdy y'all,

currently the code formatter indents the braces & sub-controls [elseif/else] to the same level as the control block. i want them indented to the same level as the code.

default ...

if ($TestBool -eq $True)    
{    
    Write-Output '$TestBool is TRUE.'    
}    
elseif ($TestBool -eq $False)    
{    
    Write-Output '$TestBool is FALSE.'    
}    
else    
{    
    Write-Output '$TestBool appears to be non-boolean.'    
}    

what i would prefer ...

if ($TestBool -eq $True)
    {
    Write-Output '$TestBool is TRUE.'
    }
    elseif ($TestBool -eq $False)
    {
    Write-Output '$TestBool is FALSE.'
    }
    else
    {
    Write-Output '$TestBool appears to be non-boolean.'
    }

yes, it fails to match your documented style. [sigh ...] however,it is far easier for _me_ to read than the style you chose.

i would dearly like to be able to set that indent style. it's whitesmith, i believe.

take care,
lee

[daviwil]

Hi Lee, not sure how I managed to forget to reply to this issue, sorry about that! We'll look into making this configurable in the future once we've gotten a little further along with the formatting.

[LeeDailey]

howdy daviwil,

thank you for the response! [grin]

i have problems seeing the break between two blocks of code using the style you folks [and many others] prefer. if you have two of the IF block shown above and use your format, the two simply blend into each other. well, to me they do ...

i look forward to each new version of your extension even more than i do to the updates for VSCode. [grin]

take care,
lee

[rkeithhill]

Given the wide assortment of brace styles, I'd rather see script formatting focus, in the short term at least, on more central scenarios/issues (if () {} else {} on same line as form of ternary op, pipeline formatting, etc) before tackling the more esoteric brace styles. :-)

BTW this setting in Visual Studio is called "Indent open and close braces" e.g.:

At least that is the closest you can get to this desired behavior in Visual Studio (and it has quite a few formatting settings). Of course that means function decls would look like this:

function foo
    {
    42
    }

[LeeDailey]

howdy rkeithhill,

that last example with the detached open brace is ... not quite on topic since the PS extension already has a setting for that. in your example, the open brace would be on the same line as the function foo and not subject to indentation.

_i_ would use it that way [grin] .others, however, would almost certainly put the open brace on the same line as the function. that is already covered by a setting and not really a part of this discussion, is it?

take care,
lee

[rkeithhill]

The point of the last example was not where the brace is but that the braces are indented and affects more than just if statements. That's all.

[LeeDailey]

howdy rkeithhill,

ah! i misunderstood that. [blush] thank you for clearing that up for me! [grin]

take care,
lee

[Jaykul]

I don't want to end up having braceStyle take a name:

• Allman/Petzold
  
  
  
  • Whitesmiths
  
  
  • GNU/Stallman
  
  
• 1TBS/OTBS (K&R)
  
  
  
  • Ratliff
  
  
  • Stroustroup
  
  
  • Java
    
    ...
  
  

Many of the indent/brace styles have actual reasons for existing _in the languages where they were conceived,_ but this is PowerShell, and many of these arguments don't hold water -- it's not worth your time to create features for which the only defensible argument is "that's how I write and I want them to be the same."

For instance the Allman style (along with Whitesmiths) are very popular in the C/C++/C# Windows world, and the justification/explanation given for them was that commenting out the _condition_ line leaves valid code -- which is true in C, but not true in PowerShell, where it would then define a scriptblock and outputs it, rather than executing it.

#if($test -gt 10)
{
    Invoke-Command $Command -Args $Test
}

It's true that the main arguments for OTBS style (that it's always safe to insert a line of code between any two lines of code) do still apply, but some distinctions don't. For instance, _in PowerShell_ K&R is the same as OTBS, because the distinction between them is that K&R allows skipping optional braces, but PowerShell doesn't have optional braces.

Finally, it's worth pointing out that several of these styles named after people do _different things_ for the brace defining a class, for a method (or a PowerShell function?), or for logic flow. Stroustroup for instance puts the brace for functions on a new line, but classes and logic on the same line...

[daviwil]

Excellent points, Joel, thanks for that! I agree, we don't want to go too far with this. We'll keep our formatting options scoped down to what makes sense for PowerShell.

[LeeDailey]

howdy y'all,

it is not so much the braces that i want indented. the style PS uses makes consecutive multi-control blocks blend into each other. try putting two IF/ELSEIF/ELSE blocks one after the other.

the nice thing about whitesmith indentation is that the primary control block is out-dented compared to all of its subsidiary components.

i suspect that this will go the way of the dodo ... but i appreciate y'alls thots on this. i _disagree_, but that is normal for me. [grin]

take care,
lee