I love this. Now to implement as:
- javascript lib / (free atom plugin with this)
- jetbrains plugin
- vim plugin
Sqlfmt: an opinionated online SQL formatter
31–40 of 94 posts
Re: Sqlfmt: an opinionated online SQL formatter
#32Brief question, only tangentially related: Is it me or is "opinionated" software popping up all over the place? It looks to me like the author considers it a selling point, too. Can someone explain to me why I would want an "opinionated" software over any regular old software? Especially over a configurable software? I'm not a native speaker, but I never encountered "opinionated" being used with positive connotation.…
"opinionated" means some options have been hidden or removed for your sake because in the author's opinion they're wrong/old/unnecessarily complex/etc.
good examples are micro frameworks that wrap very large complex APIs and simply don't pass through whole swaths of complexity.
Re: Sqlfmt: an opinionated online SQL formatter
#33Why all the SCREAMING? Is something wrong?
It's 2018, we aren't using teletypes with bad shift keys and we all have syntax coloring IDEs, we don't need to scream out all our KEYWORDS like we were still writing COBOL or FORTRAN in the 1960s.
It's become my biggest pet peeve with most SQL formatters. I think sentence cased SQL is far more readable.
Select * from sometable where SomeColumn > 3
Re: Sqlfmt: an opinionated online SQL formatter
#34Tangentially related. I'm of the opinion that SQL shouldn't be uppercased. I don't want to hit shift or caps lock and I find lowercase easier to read. Are there others out there like me? I assume I'm in the minority, but I don't understand why. People stopped uppercasing HTML tags, why can't we do the same with SQL?
My personal style is to lowercase SQL commands, but uppercase or initialcase objects like tables, columns, etc. for readability and minimal use of caps.
Re: Sqlfmt: an opinionated online SQL formatter
#35that would be really cool to have as a local package you can plug into your text editor instead of copy and paste. people using this at companies might leak sensitive information or possible attack vectors to the opaque service.
See my other comment. There are a few options for a local binary.
cool thanks!
Re: Sqlfmt: an opinionated online SQL formatter
#36Why all the SCREAMING? Is something wrong? It's 2018, we aren't using teletypes with bad shift keys and we all have syntax coloring IDEs, we don't need to scream out all our KEYWORDS like we were still writing COBOL or FORTRAN in the 1960s. It's become my biggest pet peeve with most SQL formatters. I think sentence cased SQL is far more readable. Select * from sometable where SomeColumn > 3 But I realize I'm a minori…
Yours is a fair opinion and I can't come up with any reason why it's wrong.
Personally I like it because it clearly separates keywords from objects (tables, columns, databases, etc).
This is very much like the tabs vs. spaces debate.
Re: Sqlfmt: an opinionated online SQL formatter
#37I would challenge the decision to UPPER CASE keywords, it looks oldschool and is unnecessary since syntax highlighting is ubiquitous. And right-justifying is something that only looks clean for the simplest of queries and wreaks havoc with editors that detect mixed tabs/spaces.
Re: Sqlfmt: an opinionated online SQL formatter
#38Tangentially related. I'm of the opinion that SQL shouldn't be uppercased. I don't want to hit shift or caps lock and I find lowercase easier to read. Are there others out there like me? I assume I'm in the minority, but I don't understand why. People stopped uppercasing HTML tags, why can't we do the same with SQL?
My personal style is to lowercase SQL commands, but uppercase or initialcase objects like tables, columns, etc. for readability and minimal use of caps.
That might only work if you came up with the schema or your collation is case-insensitive.
Re: Sqlfmt: an opinionated online SQL formatter
#39Tangentially related. I'm of the opinion that SQL shouldn't be uppercased. I don't want to hit shift or caps lock and I find lowercase easier to read. Are there others out there like me? I assume I'm in the minority, but I don't understand why. People stopped uppercasing HTML tags, why can't we do the same with SQL?
First, I'm sure mere inertia plays a role, but there are practical reasons as well if you're writing more than trivial SQL queries.
In most other languages you can read the statements fairly linearly, one statement leads to the next, and to the next, etc. At least within functions/methods and then you usually have indentation to help with understanding boundaries. Each "logical line" may be spread out over one or even several on-screen lines, but it's fairly easy to see the whole logical line and understand it at a glance.
Not always so with SQL.
If I get a complex SQL query to analyze, the first thing I do is not look for the SELECT clause (I'll usually have some sense of that before I start), but rather the FROM clause including it's JOINs and such. When keywords are uppercase, scanning the page for where in the statement to start my reading is much easier. Next I want the WHERE clause and its predicates... and finally I want to see what's being selected. So I'm not reading things nearly as linearly to understand a single logical statement like I would to understand say, a well written function. Also, single queries can be very long, so being able to jump around them where there are not going to necessarily be other cues can be important.
I could be wrong, but the density of user defined names (schemas, tables, columns, etc) also is higher than in other languages, so having the keywords in uppercase makes those more spread-out statement boundaries and fewer numbers of keywords in uppercase again helps me scan the statements for those major parts as I need them.
If you're writing single table queries, no sub-queries, maybe a dozen of columns or so, and only a relatively small number of WHERE clause predicates, then it might not matter much. For better or worse, that's not the world I usually find myself in :-)
Re: Sqlfmt: an opinionated online SQL formatter
#40Why all the SCREAMING? Is something wrong? It's 2018, we aren't using teletypes with bad shift keys and we all have syntax coloring IDEs, we don't need to scream out all our KEYWORDS like we were still writing COBOL or FORTRAN in the 1960s. It's become my biggest pet peeve with most SQL formatters. I think sentence cased SQL is far more readable. Select * from sometable where SomeColumn > 3 But I realize I'm a minori…
I wrote an SQL formatter as part of a larger source-to-source compiler for a re-engineering tool many years ago and ended up with initial caps for SQL keywords. E.g.
Select * From sometable Where SomeColumn > 3