-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
[headerType] Newline on the end for slashstar_style #629
Conversation
If you see examples in java, kotlin, etc., they mostly have newline after the copyright statement. mathieucarbou#186 It might be because Intellij applies header file in that way and also because in this way this would be easier to divide copyright and the code. Since customizing the headerDefinition regarding ending newline makes a quite long configuration having to reconfigure all other values, making it default might be better ƒor this plugin to be used more commonly.
@@ -43,7 +43,7 @@ public enum HeaderType { | |||
APOSTROPHE_STYLE("'", "' ", "'EOL", "", null, "'.*$", "'.*$", false, false, false), | |||
EXCLAMATION_STYLE("!", "! ", "!EOL", "", null, "!.*$", "!.*$", false, false, false), | |||
DOUBLEDASHES_STYLE("--", "-- ", "--EOL", "", null, "--.*$", "--.*$", false, false, false), | |||
SLASHSTAR_STYLE("/*", " * ", " */", "", null, "(\\s|\\t)*/\\*.*$", ".*\\*/(\\s|\\t)*$", false, true, false), | |||
SLASHSTAR_STYLE("/*", " * ", " */EOL", "", null, "(\\s|\\t)*/\\*.*$", ".*\\*/(\\s|\\t)*$", false, true, false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, but this change will break the current behaviour for existing users so this is not acceptable the way it is implemented right now.
Also, what you say might also be true for other header styles, not just java.
So we would need to find a more global solution for that, which is backward compatible also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about easier modification on the properties(changing only one property) instead of having to describe all other properties even though they don't need to be updated?
And application of EOL as a different issue?
since when EOL is applied, current behavior is adding that header even if there is a blank line at the beginning of the file.(though this is not a problem caused by plugin but it might be better to apply it in this way, since onHeaderNotFound
when header is detected, header is removed. And when that header is removed, trailing blank lines are removed. It is not exactly the same case but I guess this might look natural though this is also a breaking change T.T
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your suggestions are good yes. In HeaderType
, we can extract in a boolean endWithEOL
state whether the style finished with EOL or not. If yes, EOL will be appended when building the header style. This new property could have a default value of false when parsed from properties or XML and this way this would be backward compatible and also won't be a bug refactoring.
Unit tests will need to be added too.
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
If you see examples in java, kotlin, etc., they mostly have newline after the copyright statement. See #186 (comment)
It might be because Intellij applies header file in that way and also because in this way this would be easier to divide copyright and the code.
Since customizing the headerDefinition regarding ending newline makes a quite long configuration having to reconfigure all other values, making it default might be better ƒor this plugin to be used more common.