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

Fixes for FileStructureRule #636

Merged
merged 9 commits into from
Dec 14, 2020

Conversation

petertrr
Copy link
Member

What's done:

  • Fixed logic
  • Added tests

This pull request closes #267

@codecov
Copy link

codecov bot commented Dec 11, 2020

Codecov Report

Merging #636 (520f1c8) into master (6ea31f7) will increase coverage by 0.07%.
The diff coverage is 93.33%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #636      +/-   ##
============================================
+ Coverage     80.75%   80.82%   +0.07%     
- Complexity     1765     1771       +6     
============================================
  Files            90       90              
  Lines          4656     4663       +7     
  Branches       1403     1407       +4     
============================================
+ Hits           3760     3769       +9     
+ Misses          318      317       -1     
+ Partials        578      577       -1     
Flag Coverage Δ Complexity Δ
unittests 80.82% <93.33%> (+0.07%) 0.00 <8.00> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ Complexity Δ
...diktat/ruleset/rules/comments/HeaderCommentRule.kt 84.70% <ø> (-0.18%) 38.00 <0.00> (ø)
...tlin/org/cqfn/diktat/ruleset/utils/AstNodeUtils.kt 84.82% <ø> (ø) 0.00 <0.00> (ø)
...fn/diktat/ruleset/rules/files/FileStructureRule.kt 84.29% <92.85%> (+2.71%) 61.00 <8.00> (+6.00)
...tlin/org/cqfn/diktat/ruleset/utils/AstConstants.kt 100.00% <100.00%> (ø) 0.00 <0.00> (ø)

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 6ea31f7...520f1c8. Read the comment docs.

### What's done:
* Code style
…ow-ups#267' into feature/file-structure-rule-follow-ups#267
### What's done:
* Code style
### What's done:
* Code style
val otherNodesBeforeCode = firstCodeNode.siblings(forward = false)
.filterNot {
it.isWhiteSpace() ||
it == copyrightComment || it == headerKdoc || it == fileAnnotations
Copy link
Collaborator

Choose a reason for hiding this comment

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

What about EOL comments? Do we need to handle it here?

Copy link
Member Author

Choose a reason for hiding this comment

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

We state the following structure (as per our code style): copyright information is placed in a block comment, general file comment is placed in KDoc. All other nodes that can appear before code, including EOL comments, are captured here.

* This is an example
*/

// some notes on this file
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe it's better to add comments into KDoc?

Copy link
Member Author

@petertrr petertrr Dec 11, 2020

Choose a reason for hiding this comment

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

I check that EOL comments are moved correctly here, why would I need KDoc instead?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I thought it would be better to have one KDOC than KDOC and EOL, but I think so well)

@@ -0,0 +1,11 @@
// some notes on this file
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why COMMENT_BLOCK doesn't move exactly like the comment

Copy link
Member Author

Choose a reason for hiding this comment

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

If there is a BLOCK_COMMENT before code, it's considered as containing copyright information. But you are right, I need to check copyright keywords too, like we do in some other rule.

### What's done:
* Review notes
### What's done:
* Review notes
Copy link
Collaborator

@kentr0w kentr0w left a comment

Choose a reason for hiding this comment

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

lgtm

@petertrr petertrr merged commit d690c0f into master Dec 14, 2020
@petertrr petertrr deleted the feature/file-structure-rule-follow-ups#267 branch December 14, 2020 07:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FileStructureRule follow-ups
3 participants