For example multiple lines in this query would cause an error:

    SELECT a.field1,
      a.field2,
    --  b.field1,
    --  b.field2,
      c.field1,
    --  b.field3
    FROM a,
    --  b,
      c
    WHERE --a.field1 = b.field1
      AND a.field2 = c.field1

    SELECT 0
    , a.field1
    , a.field2
    --, b.field1
    --, b.field2
    , c.field1
    --, b.field3
    FROM dual 
    , a
    --, b
    , c
    WHERE 0=0
    --  AND a.field1 = b.field1
      AND a.field2 = c.field1

    select 
          site.name
        , site.plan
        , site.status
        , domain.domain
        , subscription.updated_at
    from
        subscription
        inner join site on subscription.site_id = site.id
        inner join domain on domain.site_id = site.id
    where
        subscription.status = 'inactive'
        and subscription.plan = 'pro'
        and domain.created_at <= '2012-04-01'
    order by
        subscription.updated_at desc

I understand the arguments for putting commas at the end of the line. For example, Google say in their style guide that when reading, having the comma at the end alerts the reader to the continuation on the next line. In languages that allow trailing commas (Python, php, C# etc) that's what I do. I put them at the front otherwise.

It's certainly not worth an overreaction though. Having commas on either end of the line isn't going to kill anyone. I've written 1000s of lines of sql in both styles and the world hasn't imploded yet.

As always, be consistent with the surrounding code - that's more important than any other rules (especially ones with a purely subjective basis).

  WHERE 1=1
  AND ...
  --AND ...
  AND ...

ORM frameworks frequently use this when they create SQL.

To this day we still give that dev (the team lead) a hard time about the trailing comma. We since implemented mandatory linting on all JS.

    myClass::myClass(int aa,int bb)
       : a(aa)
       , b(bb)
       , p(new int[aa])
       , c(17)
    {}

Having the comma in the proper place has such a negligible cost (oh no I might have to delete the comma on the last element and add it to the formerly-last element!), and having it like this looks so god awful and doesn't really save you anything if you're swapping the first element instead of the last one.

Being very dogmatic, and in a discussion of ideas saying "that's the worst thing in the world" is easily worse than comma placement. So surely commas as indentation isn't the worst thing in the world.

  select
      Field1,
      Field2,
      AnotherField
  from
      Table1

The comma controversy could be eliminated if the SQL standard was like Go's, where even the last line would have a comma.

Seriously, though, hideous syntax is bad. It makes life miserable for everyone who has to work on your code after you. Don't do it, no matter what good reasons you think you have.

I find having to re-run my query because I forgot to delete the comma following the penultimate item in the SELECT list when I commented the ultimate one out "ugly".

Additionally, everyone I have ever explained this concept to has said some variation of, "Wow, that's a great idea. Thanks!" No one has ever said, "That's the worst thing in the history of the world" ... until you.

I've been doing database work professionally for a decade now. I've explained this concept to a lot of people.

Like I said, objectively, you're just moving the extra work from moving around the last element to moving around the first element. You're not really saving any time. Plus even if you accept the argument that you are saving time (pretend you live in a world where you never move the first element) the time you save is negligible.

If you hadn't resorted to this ugly syntax, you should have developed habits that lead you to fix your commas whenever you move the last element around.

Obviously you can do what you want, but if you were on my team, I would not allow this syntax.

Except that moving the last element (more specifically appending after it) is by far the more common operation. And when you mess up on the first element, it is visually obvious that you have done so.

If you hadn't resorted to this ugly syntax, you should have developed habits that lead you to fix your commas whenever you move the last element around.

I worked with SQL for years, and never developed the habit reliably enough. Once I was introduced to the idea of the leading comma, I noticed the difference.

Obviously you can do what you want, but if you were on my team, I would not allow this syntax.

Then let's both be glad that I'm not on your team, because there are some co-workers that I don't want to have to put up with.

Thanks for that.

Changed formatting is a shock the first time. But it does not take long to retrain yourself to find it aesthetically more pleasing.

When you're making a quick fix to a batch job that does not hit the problematic query for 30 minutes, the cost of messing up the comma is 30 minutes. (Yeah, I know, it all should be properly factored out, and unit tested. But there is a lot of lightly tested code in the real world that behaves just like I said.) Because SQL is stored as plain text, there is real value in making your mental compiler have to do no work to notice stupid syntactical stuff.

Going back to my last job that was mostly SQL, I was working in Perl, with SQL embedded in TT templates. Good luck finding an IDE that understands that.

In that job the comma placement was critical. Which column would be the last column would depend on what options the report was being generated with. The point is that people would ask for many variations on the same report. One person would want a top level view, another would want to break out event type, another would want to break it out by which type of advertising campaign was thrown at it - and all were being generated out of the same templated SQL so I didn't have to maintain code in parallel. But the result is that in the code I couldn't make assumptions about which column was going to wind up being last.

Thanks to leading comma formatting, it was sufficient to require that the FIRST field stayed the same. Which proved to never be a problem.

The solution should not be hideous syntax.

At that point you can choose which is more important - the religious war or getting on with your life. When I encounter things like that my vote is a bit of both. I bring habits that allow me to cope with the methodological problem, and incrementally try to create a space where I don't have a problem.

In the process I've found that my preference for trailing commas was a useless idiosyncrasy that I could live without. When I tried living without it, I quickly found that leading commas made my life more pleasant, and I learned to like that formatting style.

Comma first seems more consistent to me.... unless you write your WHERE clauses like this:

WHERE a=b AND

a=d AND

e=f

Because it makes your SQL more legible.

In english, commas go after the previous word, not before the next word. The syntax is the same for all programming languages. The fact that most compilers and interpreters don't require it is not an excuse for abusing it.

Besides the subjective argument of legibility, what other benefits does it have?

Having a comma preceding something is an indicator that it is one of many. When debugging you can easily comment out the column, or table from a query.

And I personally prefer the rest of SQL to be in lowercase, so it does not attract too much attention. Usually in SQL table names and column names is the most important information.