-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FORMATTING] Comments move their lines after formatting #365
Comments
Currently the formatter works so that it's blind regarding original whitespace. Basically it sees the above code like this:
Or to put it another way. For the formatter these two select statements look exactly the same: select
name, -- student name
age -- student age
from
students; -- comment
select
name,
-- student name
age
-- student age
from
students;
-- comment This is currently by design. The formatter preserves no original formatting, completely reindenting the code regardless of how the whitespace was distributed originally. In that regard, it's expected that comments might be positioned differently than they were in the input. Like in your example there's identifier Another question is: how should the comments be placed? There's really two main options here: a) keep them at the end of preceding line, b) place each comment on a separate line. At the moment the formatter leans towards the first approach, though not quite purely. It basically just places them at the position where the next ordinary (non-comment) token would go. Note: the comments placement works much better when organized like so: select
-- student name
name,
-- student age
age
from
-- comment
students; In general, I think it might be a better approach to just place all comments on a separate line. In my experience, it's nearly always possible to organize your comments so that each one is on a separate line, but it's not really possible to organize all comments so that they all are at the end of a preceding line (e.g. when there are multiple single-line comments after one another). |
Thank you for your answer! How I see it there are three options for comments, that reference a single line:
Option 1 would be preferred by you and this is totally fine. I think it is the best option as well. So what would the best behaviour be?
What should never happen:
select *
from
city
-- final comment currently gets formatted to select
*
from
city -- final comment This is only a problem for single line comments, with multiline comments everything is fine: select
id
from city
/* final comment */ gets converted to select
id
from
city
/* final comment */
select
id, -- this is an id
name
from
city currently gets formatted to: select
id,
-- this is an id
name
from
city To answer your questions:
Consistency is the key, they should always be on a seperate line. If the comment was at the end of the preceding line, place them above the preceding line.
Yes, I expect them to be formatted differently, because their position changes the understanding of the code. Consider this sample output of the formatter: select
id,
-- integer ALWAYS below 20
age
from
city What column is the comment now referencing? We'll never know. |
I pretty much agree with you. I don't remember there being any changes to formatting of comments since this old issue #50. Perhaps it's time to for a small overhaul. From the top of my head I can see two things we can do to improve the formatting of comments:
The latter thing also ties in with issue #329, which also asks for ability to preserve existing whitespace. |
So this would leave comments like |
That would be trickier. Moving a comment after the line it's on is simple: one needs to just insert a newline. But moving a comment back is much more involved... we'd need to backtrack the formatting progress to the start of current line. Plus I'd rather avoid adding additional options if possible. |
This is now released in 9.2.0. |
Input data
Expected Output
Actual Output
Usage
I made these using the default settings on https://sql-formatter-org.github.io/sql-formatter/
I would be interested in getting this fixed, if you could guide me in the right direction. Seems to be similar to #50
The text was updated successfully, but these errors were encountered: