Comma-first style got quite popular among javascripters around ten years ago: gist.github.com/isaacs/357981#gistcomment-397

The main advantage IMO is being able to copy-paste lines willy-nilly and not having to spend your precious life checking whether you left a trailing comma

but I too find it ugly to read, in any language.

@CarlLange is it harder to read than any other convention that is not the one you are using?

@Kuba I mean, this is the thing, right? It's because I naturally assume commas to go at the end of lines, because that's how it would normally be in any written language I use and certainly it's the default style in any programming language I use. If my native written language didn't use commas I wonder how different my opinion would be :) I spent a long time using Lisp and that doesn't have any commas - I wonder if I'd started with it would I have the same opinion as well

I probably don't agree with semicolons-first in WL no matter what, because the semicolon has a meaning that extends to the expression before it. Commas on the other hand are dependent on an expression before and and expression afterwards

But hey, to each their own :) I have to say I really like MMA's built-in formatting for Input cells, it's a really nice feature I miss in other languages

@CarlLange Input cells are not a way to go for large code base. Unless they really do what you'd do in a text editor.

@Kuba Fair enough, I don't have experience with large WL codebases. But I do with other languages, and I constantly use automatic formatting tools so that I don't have to think about code style. When it comes down to it code style isn't really relevant to what you're doing with the code, which is why I like the way Input cells format things by themselves. Let's me focus on what I'm actually trying to do instead of what my code looks like

@CarlLange "Format code" action would be welcomed but input cells only do atuoindentation which won't fix custom linebreaks etc etc. Not to mention they are represented as boxes as opposed to input form text which makes it tough to diff.

@CarlLange Nit-picking, but: semicolons and commas are the same with respect to their surrounding elements because a; b; c is the same as CompoundExpression[a, b, c]

Admittedly there is a special case where Mathematica converts a; into CompoundExpression[a, Null] and maybe that is enough to warrant the distinction.

oh well, maybe it wasn't very good nit-picking

@C.E. OK, technically that might be the case but semantically they have different scopes, right?

googleprojectzero.blogspot.com/2019/02/…

"There are several things worth highlighting about this bug. Firstly, computational geometry is hard. Seriously. I have some experience with it and, while I can’t say I’m an expert I know that much at least. Handling all the special cases correctly is a pain, even without considering security issues. And doing it using floating point arithmetic might as well be impossible.

If I was writing a graphics library, I would convert floats to fixed-point precision as soon as possible and wouldn’t trust anything computed based on floating-point arithmetic at all. [...]"

@CarlLange for most people at least

@Kuba what all would you picture such a FormatCode action doing? One thing I've imagined doing is writing an extension to my auto-indentation and indentation converter to allow for more sophisticated processing.

The big thing I currently do is basically recursively detect RowBox switch-overs with a tracking mechanism to set some context based on what came before the RowBox.

That could be extended to take an unformatted streams of boxes and insert newlines and indentation and whatever else based on context and stuff.

Which could be a nice code-formatting tool.

Or it could also support context-based box annotations and all sorts of other little tricks and things.

I just only use it for indentation and new-line conversion