Weird GDFormat style guidelines

[tavurth]

Regarding the provided code examples, I share the opinion that the current GDFormat output could be improved to align better with popular formatting conventions:

my_array.append({
    # no-wrap
    "some": "a",
    "thing": "b",
    "is_weird": "something very long",
})

The GDFormat currently formats it as:

(
    my_array
    . append(
        {
            # no-wrap
            "some": "a",
            "thing": "b",
            "is_weird": "something very long",
        }
    )
)

The extra newline between append( and {, as well as the space between the dot and the method name, make the code a bit harder to read and deviate from common conventions.

1. Regarding the newline between append( and {:

• Black for Python: Dictionaries
• Prettier for JavaScript: Argument Expansion

2. Regarding the space between the dot and the method name:

• Python's PEP 8: Whitespace in Expressions and Statements
• Java's Code Conventions: Whitespace
• Google's C++ Style Guide: Formatting

And finally the Godot source code itself.

[tavurth]

I should note the example formatted differently I guess:

Python

my_array.append(
    {
        # no-wrap
        "some": "a",
        "thing": "b",
        "is_weird": "something very long",
    }
)

Java

my_array.append({
            "some": "a",
            "thing": "b",
            "is_weird": "something very long",
        })

C++

my_array.append({
  "some": "a",
  "thing": "b",
  "is_weird": "something very long",
})

Javascript

my_array.append({
    "some": "a",
    "thing": "b",
    "is_weird": "something very long",
})

[Scony]

I think it was discussed already in some issue but I couldn't find it. Anyway - I'd love to add support for such compact conventions but the thing is that it would take a lot of time to implement. Currently, the formatter operates in 2 modes (or strategies if you will) and chooses the one that fits better at a given point:

1. "format everything to single line" - which does exactly what it says
2. "format to multiple lines" - which formats to multiple lines and potentially falls back to 1) at deeper levels.

The correct approach to implement compact multiline formatting would be to add a new, 3rd strategy and use it in cases where it fits better. Such a strategy would require implementing custom formatting rules for all parse tree nodes which (assuming full test coverage) would require tons of man-hours to implement.

Therefore- realistically speaking - this feature probably won't ever be implemented although it would be a cool thing to have I agree.