I have no objections to a sweeping code style change removing all trailing
commas. I googled "scalafmt trailing commas" and found no ideal solution.
Based on what I read, you can simply remove line 32 from
daffodil/.scalafmt.conf (removing the line suffices since
rewrite.trailingCommas.style defaults to "never") and run "sbt scalafmtAll
scalafmtSbt". Then scalafmt will remove all trailing commas everywhere (it
would be nice if scalafmt could keep trailing commas in lists of things, but
scalafmt understands only a limited part of Scala syntax and very little of
Scala semantics).
-----Original Message-----
From: Mike Beckerle <mbecke...@apache.org>
Sent: Monday, March 4, 2024 9:48 AM
To: dev@daffodil.apache.org
Subject: EXT: Re: trailing comma 'always' scalafmt considered too ugly to
survive
Both those code examples you showed have almost no function calls. The only
examples of trailing commas in those are lists of uniform things.
It is not in lists of things that I care about this issue.
It is in argument lists of function calls, tuples, and formal argument list
definitions, and tuple type definitions.
In these cases, adding another item isn't just a one-line change, it requires
agreement between a definition and a point of use.
Those code snippets you listed showed nothing like this:
val var = foo(
big long expression that takes up a good fraction of a line,
short expression one,
)
That's the case that I find not just ugly, but distracting and it decreases my
working speed.
There are just the two arguments, so there is not enough uniformity there to
recognize it as a list, where an extra comma might be ok.
Also:
val var = foo(
just one argument, but a big long line of it.,
)
That trailing comma is simply disturbing. There's no list there, just one thing.
def foo(
thisArgumentNameIsVeryDescriptive: VariableRuntimeDataHelper, // note:
changed to be the Helper object
)
There too, the trailing comma is problematic. It's a penalty for being
descriptive and trying to create self-documenting code.
Similarly, return tuples:
def foo(): (
Map[String, VariableRuntimeDataHelper], // specific map, not the regular
variable-map
Variable,
)
I find trailing commas in that situation equally troubling.
The "convenience" of being able to put a comma in these places is completely
outweighed by the uncertainty it creates about intent.
For lists/sequences of things, meaning the things are of the same type, with 4
or more items, and it's clear that one line per list entry is desirable, then
I have no issue with trailing commas, though since tools like scalafmt can't
recognize this I believe to make arg lists and tuples not have trailing commas
one must rule them out in all cases.
I'd like to do a sweeping code change to remove the trailing commas, setup
scalafmt to remove them, and be done with this whole thing.
On Mon, Mar 4, 2024 at 8:22 AM McGann, Mike <mmcg...@owlcyberdefense.com>
wrote:
> Python allows dangling commas and there tends to be encouraged:
>
> https://github.com/python/cpython/blob/3.12/Lib/logging/__init__.py#L1
> 13
>
> In Go, they are required by the syntax:
>
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.22.0:src/go/token/t
> oken.go;l=233
>
> JavaScript allows it too but that is more of a preference thing (same
> thing with using semicolons or not).
>
> I can't say that I've seen common use of the comma preceding content
> on a line.
>
> // Mike
>
>
> -----Original Message-----
> From: Mike Beckerle <mbecke...@apache.org>
> Sent: Friday, March 1, 2024 18:51
> To: dev@daffodil.apache.org
> Subject: Re: trailing comma 'always' scalafmt considered too ugly to
> survive
>
> I've actually seen this coding style for the same reason:
>
> val x = Seq( // format: off
> 1
> ,2
> ,3
> ) // format: on
>
> Tolerating or as we have now, requiring dangling commas everywhere
> feels like a bad trade off when a simple trick like this also works.
>
>
> On Fri, Mar 1, 2024 at 5:53 PM Steve Lawrence <slawre...@apache.org>
> wrote:
>
> > I don't know if it's a very very good reason, but I think the main
> > benefit is making diffs more clear when adding to a list.
> >
> > Without trailing commas you get a diff like this:
> >
> > Seq(
> > 1,
> > - 2
> > + 2,
> > + 3
> > )
> >
> > But with trailing commas the diff is this:
> >
> > Seq(
> > 1,
> > 2,
> > + 3,
> > )
> >
> > IMO, the latter makes it much more clear that you're just adding "3"
> > to the Seq and makes code review a little easier.
> >
> >
> > On 2024-03-01 05:36 PM, Mike Beckerle wrote:
> > > Why oh why did we ever do this?
> > >
> > > Is anyone very attached to this dangling comma stuff in our
> > > current scalafmt rules?
> > >
> > > I am at this point, vehemently opposed to this code style, and
> > > very much want us to switch back to not allowing dangling commas.
> > >
> > > I've spent hundreds of hours now working this code base with this
> > scalafmt
> > > convention, and I have never gotten used to it. I continue to be
> > > slowed down by this style, which makes it hard to read the code
> quickly.
> > > I also find it unaesthetic and frankly just annoying. One of the
> > > things I like about Scala is not having excess punctuation like
> > > Java's semicolons
> > at
> > > the end of every statement.
> > > The cleaner, simpler Scala syntax is very nice. Why would we ugly
> > > it up with trailing commas? To me if you're going to do that one
> > > might as well
> > go
> > > back to coding in Java.
> > >
> > > ?Punctuation, characters need. to be used; (correctly or it is, )
> > > simply annoying as hell .
> > >
> > > Unless someone has a very very good reason why this should not
> > > change,
> > I'm
> > > very inclined to go back to scalafmt trailingCommas = never behavior.
> > >
> > > Thoughts?
> > >
> > > Mike Beckerle
> > > Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup
> > > Co-Chair |
> > www.ogf.org/ogf/doku.php/standards/dfdl/dfdl
> > > Owl Cyber Defense | www.owlcyberdefense.com
> > >
> >
> >
>
