Live data from Hacker News

Sqlfluff the SQL Linter for Humans

sqlfluff.com

41–50 of 95 posts

Re: Sqlfluff the SQL Linter for Humans

#41
post #22
post #11

There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc

Yes! I write SQL this way. I grant the comma thing is more a matter of taste, but aligning clauses vertically and maximizing rivers is super useful to me and it forever mystifies me that it isn't standard. This is an extreme example, but I like to keep join clauses vertically aligned as well: select a , b , count(*) as count from table join table2 on table.key1 = table2.key1 and table.key2 = table2.key2 and DATEADD('…

That formatting makes my eyes bleed.

Re: Sqlfluff the SQL Linter for Humans

#42
post #11

There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc

could a synonym for "more not-noob" perhaps be "more esoteric"?

Re: Sqlfluff the SQL Linter for Humans

#43
post #11

There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc

This whole discussion here shows that the best time to introduce a linter/autoformatter is at the same time as the language it's supposed to lint/format (like Go did). Otherwise you will have interminable discussions and everyone will want their favorite style supported. I'm afraid that ship has sailed for SQL though...

Re: Sqlfluff the SQL Linter for Humans

#44
post #11

There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc

If SQL would just allow a trailing comma on the last column, none of this leading comma shit would be necessary. I still use trailing commas, because code readability is more important that writeability IMO, but the fact that I'm forced to sympathize with such an ugly shit sandwich is really frustrating. Can't sympathize with the clause alignment though. And I can't figure out why someone who does leading commas for…

Yes, despite knowing how to do it right those damn comma issues always come up at the worst time and to add insult to injury they're reported by most of the tools I have available like they're totally insoluble to the computer (even though far more taxing things are routinely fixed automatically).

Re: Sqlfluff the SQL Linter for Humans

#45
post #22
post #11

There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc

Yes! I write SQL this way. I grant the comma thing is more a matter of taste, but aligning clauses vertically and maximizing rivers is super useful to me and it forever mystifies me that it isn't standard. This is an extreme example, but I like to keep join clauses vertically aligned as well: select a , b , count(*) as count from table join table2 on table.key1 = table2.key1 and table.key2 = table2.key2 and DATEADD('…

Do you format your code this way by hand or does your IDE help you? Also, I can only imagine how noisy your diffs would be when you make changes and have to indent everything.

Re: Sqlfluff the SQL Linter for Humans

#46
post #37

Earlier quoted context omitted.

It seems to have a formatter option in the `fix` argument you can give it. The authors should probably be selling it on that point since it seems to be its strength, it doesn't have many rules along the lines of the static analysis that people look for in linters. Some people (tech leads, CTOs) care a lot about formatting but I wouldn't make teammates go through a linter for that, it's a rather surface concern.

The reason that those people care about formatting is that it matters when the code is used to communicate with other people, not just with machines. Having a consistent style within the team, means the team can communicate more easily - even if the net effect for an individual working on a codebase alone is minimal.

Yes but realistically, save for the code that someone who's really inexperienced or sloppy would write, fixating over whether someone is writing

     select a, b, c
     from foo
     where bar = 'quux'
rather than

     SELECT
         a,
         b,
         c
     FROM
         foo
     WHERE
         bar = 'quux'
is petty and immaterial to what the code communicates.

Worse if it's about details within the roughly the same style.

Edit: but if there's a code formatter that can be seamlessly added to the development environment, it makes sense to use it. It's just that if there's no tool support, such things are of little contribution.

Re: Sqlfluff the SQL Linter for Humans

#47
post #22

Earlier quoted context omitted.

Yes! I write SQL this way. I grant the comma thing is more a matter of taste, but aligning clauses vertically and maximizing rivers is super useful to me and it forever mystifies me that it isn't standard. This is an extreme example, but I like to keep join clauses vertically aligned as well: select a , b , count(*) as count from table join table2 on table.key1 = table2.key1 and table.key2 = table2.key2 and DATEADD('…

Do you format your code this way by hand or does your IDE help you? Also, I can only imagine how noisy your diffs would be when you make changes and have to indent everything.

I'll use PyCharm's SQL formatter sometimes to massage spaghetti code that someone else wrote, but mostly I just write it this way by hand.

I will say my use case is probably different than others, I'm a Data Scientist so I write a ton of throwaway SQL and stuff that will only be seen by me. If I'm dealing with an existing SQL codebase or production stuff, definitely try to keep it more easily diff-able (like left justifying the keywords, really only caring about rivers in the join/where clauses), or just follow whatever patterns are already there.

Re: Sqlfluff the SQL Linter for Humans

#48

Earlier quoted context omitted.

I hate you and and the awful layout you have just introduced me to... Also, that is how I will be formatting all my SQL from now on.

alt styling SELECT a, b, COUNT(*) as count FROM table WHERE cond1 AND cond2 GROUP BY a, b ORDER BY count DESC

That's the one I'm familiar with. The capitalized keywords help give you that Relational Database feel.

Re: Sqlfluff the SQL Linter for Humans

#49
Most of the rules seem reasonable, but what's the justification for this?

Rule_L031: Avoid table aliases in from clauses and join conditions.

I can't see what makes aliases clarifying in `select` or `where` but not in `join`. Also, inlined subqueries in a join must be given an alias, so there are cases where this rule can't be applied consistently.

Re: Sqlfluff the SQL Linter for Humans

#50
post #11

There surely is a need for a sql linter, but if it wants to be strict about syntax style, it should better familiarize itself with not-noob styles first. Eg. some people like to align the clauses vertically and use a leading, not trailing, comma. select a , b , count(*) as count from table where cond1 and cond2 group by a, b order by count desc

I hate you and and the awful layout you have just introduced me to... Also, that is how I will be formatting all my SQL from now on.

I’ve always formatted my SQL like this, but I don’t remember learning it from anyone else or seeing anyone else do it.
Post reply on HN