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

Implement MultilineRawStringIndentation #5058

Merged
merged 7 commits into from Aug 1, 2022

Conversation

BraisGabin
Copy link
Collaborator

This implements one of the proposed rules in #4705

To be more precise it implements this one:

When using trimIndent() or trimMargin() check that the left-most indentation is indented x characters from the enclosing element

This rule was a complex one. Format is hard >_<.

@BraisGabin BraisGabin added this to the 1.22.0 milestone Jul 9, 2022
Base automatically changed from MultilineRawString to main July 18, 2022 12:24
@BraisGabin BraisGabin force-pushed the MultilineRawStringIndentation branch from 5ff5f44 to 5f239fc Compare July 20, 2022 17:29
@BraisGabin BraisGabin force-pushed the MultilineRawStringIndentation branch from 5f239fc to 37ac386 Compare July 20, 2022 17:38
@BraisGabin BraisGabin changed the base branch from main to getLineAndColumnInPsiFile July 20, 2022 17:38
Base automatically changed from getLineAndColumnInPsiFile to main July 20, 2022 17:58
@schalkms
Copy link
Member

@BraisGabin did you mix up the changes required for this new rule with another branch? In particular, this PR seems to include too much.

@BraisGabin BraisGabin force-pushed the MultilineRawStringIndentation branch from 37ac386 to 27b256c Compare July 21, 2022 07:43
@BraisGabin
Copy link
Collaborator Author

Yes, I had one extra commit (the squash strategy doesn't work too good with chained PRs).

Probably this PR could be reviewed commit by commit. There are two prior refactors that I needed: One to be able to tests this PR properly and other to reduce the duplicated code.

I can split this PR if you feel it will make it easier to review.

Copy link
Contributor

@marschwar marschwar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will finish tomorrow. Just a few comments now ;)

.onEach { (lineNumber, line, currentIndent) ->
val location = containingFile.getLocation(
SourceLocation(lineNumber, if (line.isBlank()) 1 else currentIndent + 1),
SourceLocation(lineNumber, line.length + 1)
)

report(this, location, message(desiredIndent, currentIndent))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually want to report one violation for each line that is incorrectly indented? Consider a code block like in detekt tests. If you get the indentation wrong, it is most likely wrong for entire block. Would it not be enough to mark the multi line string as a violation as a whole? That most likely would make the rule much easier to implement.

Specifically I do not like the fact that

val a = """
Hello world!
How are you?
""".trimIndent()

produces 2 violations, while

val a = """
        Hello world!
        How are you?
""".trimIndent()

produces one

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes... this was a difficult decission. I was thinking about a long raw string with only one/few lines with the wrong identation. In that case I wanted to point out exactly which line was the wrong one. The problem is that if all of them are wrong I end up raising all of them

The second case was easy because if it happens I know that all the lines are wrong so I just raise the error once.


I feel that this is a tradeoff:

  • If I raise only one the cases where all of them are wrong will be easier,
  • But if only some of them are wrong this approuch would be better.

🤷 I'm fine with both of them to be honest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I think the code could have been easier to write and to maintain if it were just one violation per multi line string, but I see your point.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm merging it like this. We can always revisit this once we get the users feedback.

@BraisGabin BraisGabin force-pushed the MultilineRawStringIndentation branch from 487cee5 to 956b99d Compare July 23, 2022 11:13
@BraisGabin BraisGabin changed the base branch from main to assert-end-source-locations July 23, 2022 11:13
@github-actions github-actions bot removed the api label Jul 23, 2022
@BraisGabin
Copy link
Collaborator Author

@marschwar Thank you so much for the this great review :). I fix some of your comments and answer others.

I'm not against the changes that you point our in the comments were I answered I just wanted to share the why behind that code/decission. If you still think that it would be beneficial to change that part of the code I will change it :)

@codecov
Copy link

codecov bot commented Jul 23, 2022

Codecov Report

Merging #5058 (e4a2bf5) into main (e4a2bf5) will not change coverage.
The diff coverage is n/a.

Current head e4a2bf5 differs from pull request most recent head ab9ab07. Consider uploading reports for the commit ab9ab07 to get more accurate results

@@            Coverage Diff            @@
##               main    #5058   +/-   ##
=========================================
  Coverage     84.91%   84.91%           
  Complexity     3614     3614           
=========================================
  Files           502      502           
  Lines         11887    11887           
  Branches       2237     2237           
=========================================
  Hits          10094    10094           
  Misses          690      690           
  Partials       1103     1103           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e4a2bf5...ab9ab07. Read the comment docs.

@marschwar
Copy link
Contributor

I'm not against the changes that you point our in the comments were I answered I just wanted to share the why behind that code/decission. If you still think that it would be beneficial to change that part of the code I will change it :)

Same here. I do not feel strongly enough about them but wanted to discuss them with you.

@BraisGabin BraisGabin force-pushed the MultilineRawStringIndentation branch from 956b99d to b115929 Compare July 23, 2022 14:12
Base automatically changed from assert-end-source-locations to main July 23, 2022 14:34
BraisGabin and others added 7 commits July 23, 2022 16:43
…/rules/style/MultilineRawStringIndentation.kt

Co-authored-by: marschwar <marschwar@users.noreply.github.com>
…/rules/style/MultilineRawStringIndentation.kt

Co-authored-by: marschwar <marschwar@users.noreply.github.com>
…/rules/style/MultilineRawStringIndentation.kt

Co-authored-by: marschwar <marschwar@users.noreply.github.com>
…/rules/style/MultilineRawStringIndentation.kt

Co-authored-by: marschwar <marschwar@users.noreply.github.com>
@BraisGabin BraisGabin force-pushed the MultilineRawStringIndentation branch from b115929 to ab9ab07 Compare July 23, 2022 14:43
@BraisGabin BraisGabin merged commit 9acad77 into main Aug 1, 2022
21 checks passed
@BraisGabin BraisGabin deleted the MultilineRawStringIndentation branch August 1, 2022 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants