Add "collapse-one-line" option for non-collapse brace styles

[Sevin777]

Would it be possible to add an option that makes brackets stay on the same line after a conditional statement IF there is only one line of code after the conditional?

Example:

if(a==1) { a++; }

right now this gets turned into:

if (a == 1) {
      a++;
}

or (depending on options):

if (a == 1)
{
    a++;
}

Using brackets for a single line after a conditional is good practice as it prevents ambiguity and stupid mistakes for what is going to execute after the conditional. However, reading code that requires either 3 or 4 lines (depending on current options) for a single line conditional and single line result is tedious as it takes up far too much space.

[fabien-h]

a === 1 && a++;

:)

[bitwiseman]

Interesting idea, but it isn't high on our list of requests.

[laggingreflex]

+1 Not just for if-else, but it'd be useful for small objects

UserDB.findOne({username:'xyz'}, function(err, user){...

[bitwiseman]

Similar to #315

[bitwiseman]

This some forms of this may be covered by 1.6.0, but it has not been fully tested.

[laggingreflex]

hmm just pulled the latest but these are still the same:

if (a == 1) {
  a++;
}

a = {
  a: a
};

UserDB.findOne({
  username: 'xyz'
}, function(err, user) {});

import {
  fs
} from 'fs';

[bitwiseman]

If you set `brace_style=collapse-preserve-inline" and provide the inline versions as inputs these work:

if (a == 1) { a++; }

a = { a: a };

UserDB.findOne({ username: 'xyz' }, function(err, user) {});

import { fs } from 'fs';

[Sevin777]

Thank you for working on this. Unfortunately, the result does not work for me because it's implemented as a new brace-style collapse-preserve-inline that is really a subset of an existing brace style collapse.

I use the end-expand brace-style (which is the most common for formatting JavaScript). Ideally, there should be a separate option for preserve-inline, which is compatible with with all of the existing brace-styles (except none, which does not mess with braces). Another option would be to add brace styles expand-preserve-inline and end-expand-preserve-inline.

The current solution only works for a very small subset of users who actually prefer the collapse brace style.

Also, there is another issue in that the new collapse-preserve-inline style messes up conditional line breaks:

// input sample (want to keep this formatting)
if (a == 1) {a++;}
else if (a == 2) {
    a++;
    b++;
}


// using collapse-preserve-inline.
// this is very undesirable... now my control statements are on the same line
if (a == 1) { a++; } else if (a == 2) {
    a++;
    b++;
}

If the above ideas were implemented (and the bug fixed), then we would likely have a working solution.

The 'perfect' solution would require a lot of work (and is likely not going to happen):
The way that Visual Studio handles C# formatting is a great example of how the formatting should work ( C# syntax is almost identical to JavaScript in terms of new line formatting). It allows very advanced configuration for when new lines are created, and more importantly, you can override the default formatting by editing the code (such as putting braces inline when they would normally be in a new line) and the next time you auto format the document it does not override your inline braces. I think part of the reason this works is because it auto formats sections when a closing brace is typed (try this demo for my implementation of this with JS Beautify - type a closing brace and it will auto format the contents between braces). It would be great if JS beautify could work this way... but I understand it would require a lot of work and this is an open source project.

[bitwiseman]

Thank you for following up and continuing to provide feedback.

When I was implementing the preserve-inline, I considered that people my want expand with preserved inline blocks and then thought "Nah, why would anyone do that?" 😄 And as usual, I was wrong.

What you describe as a bug in if-else is technically correct behavior for "collapse" (else should be on the same line as the closing brace). 😢 Sorry.

What you're talking about for perfect solution would require full parsing of the javascript (see #200). And you're also talking about the difference between formatting in the editor vs formatting of a whole file. And yes much more work to implement, and then the combinatorial problem of testing the interactions between all those options. There are other projects that are attempting to provide this level of granularity, but it isn't a goal of this project.

I'll reopen this, but we are again back to low priority. I would welcome a pull request that added `expand-preserve-inline' and 'end-expand-preserve-inline' (or even one that moved the preserve inline to a separate setting), assuming it included tests and the python port.

Just for reference, the main change for preserving inline is here:
55f111e#diff-655cdbdfd52b6516fe4d5d2e53a7af50R797

It might not be that hard to add the functionality you're suggesting.

[bitwiseman]

@sevin7676 - please see 1.6.6 and #1052 . I think this issue is addressed. Please reopen if it is not.