Here is some Go code use with trailing commans in function declaration and invocation:
https://go.dev/play/p/avjdriC_x6b In both those examples, the comma is required. Removing it causes a syntax error and I think this is due to the ASI rules and when a virtual semicolon can be inserted. Therefore, I don't consider trailing commas to be ugly, more of something that happens from time to time depending on usage. I also don't think tabs are ugly, but that is always up for debate. That being said, I'm not partial to trailing commas or not, but I am a true believer in a code formatter. Some of my early pull requests were filled with review comments that could be easily resolved with one. Using tools to make a consistent look in the source code is much easier than memorizing a style guide in which rules change from project to project. The actual style itself is always up for debate. // Mike -----Original Message----- From: Mike Beckerle <mbecke...@apache.org> Sent: Monday, March 4, 2024 12:48 To: dev@daffodil.apache.org Subject: 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 > > > > > > > >
