Discussion: hugging formatting for dictionaries and using commas as formatting hint

[Shatur]

The following code:

for i in range(3):
	properties.append({
		"name": "number_%d" % i,
		"type": TYPE_INT,
		"hint": PROPERTY_HINT_ENUM,
		"hint_string": "ZERO,ONE,TWO,THREE,FOUR,FIVE",
	})

Will be formatted like this:

for i in range(3):
	properties.append(
		{
			"name": "number_%d" % i,
			"type": TYPE_INT,
			"hint": PROPERTY_HINT_ENUM,
			"hint_string": "ZERO,ONE,TWO,THREE,FOUR,FIVE",
		}
	)

But I think the original version reads better. I took the code from this example.

Also if the dictionary is shorter (I just removed the last line from the previous example):

for i in range(3):
	properties.append({
		"name": "number_%d" % i,
		"type": TYPE_INT,
		"hint": PROPERTY_HINT_ENUM,
	})

It will be formatted like this:

for i in range(3):
	properties.append({ "name": "number_%d" % i, "type": TYPE_INT, "hint": PROPERTY_HINT_ENUM })

But I'd expect the shape to be preserved since I have a comma at the end.

[NathanLovato]

There are two things here:

• Wanting a compact style for dictionaries/structures
• Wanting to manually control line wrapping with trailing commas

For 1. this kind of works well when there's this very specific case of having a single multiline argument but it does not necessarily apply or work across the board. Right now, I'm trying to find general rules that work across the board and give people a consistent experience.

Consider this call expanded to 3 arguments with a hugging layout rule:

for i in range(3):
	my_function("argument_1", {
		"name": "number_%d" % i,
		"type": TYPE_INT,
		"hint": PROPERTY_HINT_ENUM,
	}, "argument_3")

In the specific case that you showed, yes, it looks neat, but before implementing a rule we need to consider all the cases and what it does to entire files or codebases. The reason the lines wrap is actually for getting a relatively consistent and intuitive output across the board.

For 2. driving the formatting based on the user input. Right now, the formatter automatically inserts trailing newlines automatically and the philosophy is generally to format as automatically as possible and require no or as little any user input as possible. But not inserting newlines for you and instead using that as a hint to force keeping things multiline is up for consideration, sure. Just gotta think about it beyond this one case. I think Python's black does that, I don't mind copying what they do even if the reason is just that people are used to it and enjoy that feature. But I'd like more input.

[JeanMariePrevost]

Adding my $0.02 for the comma part: I was surprised by the lack of "trailing comma means multiline." Even the GDScript style guide indirectly hints at this in my opinion

I'm used to trailing comma to indicate that an array, dictionary, function call, or parameter list is deliberately multiline. I've always seen "trailing comma = explicit multiline, no trailing = automatic behavior" and I think it would fit perfectly here. Deterministic, lightweight and idempotent.

This would make automatically wrapped blocks remain multiline until the trailing comma is removed, but personally I prefer that stability. Even if it isn’t the default behavior, I’d love to see it available as a configuration option.

[NathanLovato]

Thank you, that makes sense, I'm definitely taking note. I'm also going to test a few more formatters. I've tested that in black, which is kind of the main reference for this one.

In general, I'm interested in any user-controlled outputs that you are used to in formatters that are very mature for other languages. By that I mean like this comma thing: manually inserting a last trailing comma to force a multiline layout

A teammate showed me something that the Zig formatter does, where if you have a matrix represented in an array, you can insert a line break, for example, after the fourth element, and it will keep four elements per line automatically. That arranges it as a 4x4 grid. That seems like something useful for arrays specifically whenever representing a grid in an array.

feedback or your experience with any kind of thing like that is much welcome, even if some are more niche or lower priority. Because some of these things, they're probably documented somewhere, but it takes time to go find the information and understand why it's been done for this language and if it's transferable to GDScript and useful in the context of gamedev.