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

Issue #14716: Fix the violation for modifiers wrapped in class def #14743

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

@kalpadiptyaroy
Copy link
Contributor Author

We can test any potential scenario by adding that case to this file.
InputIndentationClassDeclarationWrapped.

Welcome to every suggestion.

@kalpadiptyaroy
Copy link
Contributor Author

GitHub, generate report

Copy link
Contributor

Report generation failed on phase "make_report",
step "Generate report".
Link: https://github.com/checkstyle/checkstyle/actions/runs/8495975615

@kalpadiptyaroy
Copy link
Contributor Author

GitHub, generate report

@kalpadiptyaroy
Copy link
Contributor Author

Above report is without openjdk17 (excluded since it is raising OutOfMemoryException)

@kalpadiptyaroy
Copy link
Contributor Author

GitHub, generate report

@kalpadiptyaroy
Copy link
Contributor Author

Generating a new report - including new popular open-source java repos.

Copy link
Member

@romani romani left a comment

Choose a reason for hiding this comment

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

items:

* @param node the node whose predecessors are to be checked.
* @return true if node is preceded by an access modifier else false.
*/
public static boolean isPrecededByAnyModifier(DetailAST node) {
Copy link
Member

Choose a reason for hiding this comment

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

please move it to src/main/java/com/puppycrawl/tools/checkstyle/checks/indentation/AbstractExpressionHandler.java
and test it by InputIndentationxxxxxxx.java not a pure junit.

Comment on lines +504 to +507
&& (!TokenUtil.isOfType(modifier,
TokenTypes.ANNOTATION, TokenTypes.STRICTFP, TokenTypes.LITERAL_STATIC)
|| modifier.getPreviousSibling() == null
|| !isPrecededByAnyModifier(modifier))
Copy link
Member

@rnveach rnveach Apr 1, 2024

Choose a reason for hiding this comment

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

@romani @nrmancuso

I am continuing on the discussion at #14716 (comment) , I don't see how skipping specific tokens will serve a benefit. I don't think we should be reviewing this PR until we have some agreement here. There doesn't seem to be any clear reason why we are targeting these tokens. For example, why is static on this list and not public? How did we choose these specific tokens that we can explain to others.

Including @nrmancuso 's original comments, the input file in this PR needs to be vastly expanded.

We need a duplicate input file with all indentation at 0 showing the violations produced by bad code. Regression was done on good formatted code, so it will provide less value for this check in those terms. We should also do force strict as it will tell us exactly what indentation should be and when it is absolutely correct and not just meeting the min requirement.

We also need inputs where these tokens being skipped are completely alone on a line and are the first AST in the class def. All the current examples start with public, abstract, final which are not any of the tokens listed here.

Copy link
Member

Choose a reason for hiding this comment

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

There doesn't seem to be any clear reason why we are targeting these tokens

Yep, my sentiments exactly.

@kalpadiptyaroy
Copy link
Contributor Author

@rnveach - I agree with you. We must rigorously see the regression of this patch on dirty codes elaborating as many scenario's as possible and then make a move.

I will try and keep preparing samples of dirty codes with wrappings in class defs in as many possible ways as I think of and compare the regression reports.
I will be discussing that in issue thread and we only come back to PR when everyone is in agreement and confident of this move.

@romani
Copy link
Member

romani commented May 11, 2024

@kalpadiptyaroy, please find time to finish this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants