Vote for the default style of list/record/match branches/parameter list/type parameters

[blindFS]

We want to collect preferences from different users on this topic.

Related issues #16 #30

[blindFS]

Examples of match branch

match $foo {
  1 => 1
  true => 2
}

match $foo { 1 => 1 true => 2 }

match $foo {
  1 => 1,
  true => 2,
}

match $foo { 1 => 1, true => 2 }

Examples of parameter list

def foo [bar: bool baz: record<a: int, b: bool>] { }
{|foo bar| $foo}

def foo [
  bar: bool
  baz: record<a: int, b: bool>
] { }

def foo [bar: bool, baz: record<a: int, b: bool>] { }
{|foo, bar| $foo}

def foo [
  bar: bool,
  baz: record<a: int, b: bool>,
] { }

[Bahex]

In multi line expressions, the last item should have a trailing comma too (reduces noise in diffs, can make batch editing simpler)

[WindSoilder]

I like to have commas always.

[blindFS]

I like to have commas always.

Thanks for voting!

[Juhan280]

My personal preferance: no comma unless its a single line record/match expression/parameter list

[blindFS]

Yes, except that pr also adds commas in single line list. But for me personally, single line list with just space delimeter is readable. But single line records/match/etc without comma looks confussing

I respect your choice for single-line list, just want to remind you that the list example above might be too simple, I don't know if something like [(echo foo) [bar baz]] will change your mind.

[Juhan280]

Nah, I already considered this case. Here we are using brackets and so there is no confussion

[blindFS]

Nah, I already considered this case. Here we are using brackets and so there is no confussion

Fair point.

[ItsHarper]

I'm on board with this opinion too

[blindFS]

I'm on board with this opinion too

Just vote for option 4, probably never gonna be the mainstream though.

[blindFS]

For those who choose option 1, there's now a draft PR #34. Please comment on it if you find any unexpected behavior while trying that branch.

I believe they're trying to add a new feature of smart detecting preferred styling based on the input code on the topiary project. I've no idea how long will it take to merge #34 , maybe the auto detecting feature will land first and we won't need it anymore.

[hongquan]

Me:

• No comma for list items.
• No comma for multi-line.
• Commas for the rest.

[blindFS]

Thanks for sharing your thoughts, I suppose they're exactly the same to Juhan280's. You can vote for option 4.

In terms of implementation, I'm afraid you will have to wait for the smart style detecting feature of topiary to make that happen.

[x8x]

While I agree that commas make single-line code easier to scan, I think the single-line style is best suited for CLI use, where you typically want to write less and do more—so you might as well skip commas there too.
In actual code, I see no reason to condense everything into one line. Having one parameter per line is much more readable and makes it easier to comment things out when experimenting. In multiline code, commas only distract the eye.
In cases where it makes sense to inline a list in code, it’s probably something short like [1 2 3 4 5], and even there, commas tend to be more distracting than helpful.