Skip to content
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

Empty line between if-else-if ladders gets removed thus ruining readablity. #348

Open
Aspecky opened this issue Jan 31, 2022 · 9 comments
Open
Labels
enhancement New feature or request requires option This feature request would require option configuration rfc/in discussion This issue is currently in discussion, comments are welcome!

Comments

@Aspecky
Copy link

Aspecky commented Jan 31, 2022

Lot of times I have these inevitable if-else ladders and it gets a bit hard finding my way through them which is why I leave an blank line before my next elseif so it becomes easier to read, like this:

if true then
    local var = 2
    var += 1
    var += 1
    var += 1
	
elseif true and not true then
    local var = 3
    var += 1
    var += 1
    var += 1
end

But the formatter removes that blank line and kills readability for me, so it becomes like this:

if true then
    local var = 2
    var += 1
    var += 1
    var += 1
elseif true and not true then
    local var = 3
    var += 1
    var += 1
    var += 1
end

And it gets much worse the longer the code is and the longer the ladder is.
I think there should be an option to leave blank lines there for people like me.

@dphfox
Copy link

dphfox commented Jan 31, 2022

I do the same thing, this would be much appreciated.

@JohnnyMorganz
Copy link
Owner

Interesting, personally I find the difference in indent helps, but I can definitely see where you are coming from.

I wonder if we should just leave a newline at the end of an if block if one was present originally. It might be reasonable rather than a whole option for it. Also, do you only keep this newline for blocks above another block? (i.e., you don't have a newline between the last block and end)

@JohnnyMorganz JohnnyMorganz added enhancement New feature or request rfc/in discussion This issue is currently in discussion, comments are welcome! labels Jan 31, 2022
@Aspecky
Copy link
Author

Aspecky commented Jan 31, 2022

Oh right, I forgot to mention that, if there was an empty line in the last end, it should be removed, because it doesn't serve any purpose.
So this:

if true then
    local var = 2
    var += 1
    var += 1
    var += 1
	
elseif true and not true then
    local var = 3
    var += 1
    var += 1
    var += 1

end

Would become this:

if true then
    local var = 2
    var += 1
    var += 1
    var += 1
	
elseif true and not true then
    local var = 3
    var += 1
    var += 1
    var += 1
end

@LastTalon
Copy link
Contributor

Personally, I do not like the idea of this happening. I would want StyLua to reformat this and remove this blank line in code I format with it. Part of why I use StyLua is to remove formatting decisions like this and so my code is formatted the same each time.

@Aspecky
Copy link
Author

Aspecky commented Jan 31, 2022

Personally, I do not like the idea of this happening. I would want StyLua to reformat this and remove this blank line in code I format with it. Part of why I use StyLua is to remove formatting decisions like this and so my code is formatted the same each time.

Which is why this could be a toggleable option in the settings, that will satisfy both parties.

@LastTalon
Copy link
Contributor

Which is why this could be a toggleable option in the settings, that will satisfy both parties.

Yeah, this would be better. I was mostly referring to this:

I wonder if we should just leave a newline at the end of an if block if one was present originally.

@JohnnyMorganz JohnnyMorganz added the requires option This feature request would require option configuration label Dec 23, 2023
@alerque
Copy link
Contributor

alerque commented Dec 23, 2023

I wonder if we should just leave a newline at the end of an if block if one was present originally.

No, that would ruin the reproducibility. Personally this is an option I won't use. I don't care if the feature gets added, but having it decide whether or not to do something based on the input formatting ruins the predictability of what would come out. Putting it behind an configuration option would allow it it exist as a feature without messing up those of us that would prefer actual normalization.

@JohnnyMorganz
Copy link
Owner

JohnnyMorganz commented Dec 23, 2023

+1 there. I no longer agree with the idea of relying on input to determine output. The most major problem being that in a project it now depends on how the user originally formatted the code (and then style nits all come back again! "Please delete this newline").

This feature, if added, would be added behind an option and would apply in all cases

@mg979
Copy link

mg979 commented Jul 2, 2024

Any news on this? Just my 2 cents, but I don't think an option is needed, since stylua already respects single empty lines most of the times, even inside tables. Can't the rule be simply to preserve empty lines where they are, trimming multiple empty lines into one at most? If option should be, maybe allow the user to specify how many empty lines to preserve:

preserve_empty_lines = 2

And in that case, never remove empty lines anywhere, up to that value of consecutive empty lines.

But imho empty lines aren't a formatting issue, it's easy to delete them yourself, but if you actually want them and the formatter keeps deleting them, that's an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request requires option This feature request would require option configuration rfc/in discussion This issue is currently in discussion, comments are welcome!
Projects
None yet
Development

No branches or pull requests

6 participants