-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[prone] Add UnusedVariable
#11284
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
base: master
Are you sure you want to change the base?
[prone] Add UnusedVariable
#11284
Conversation
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.
Can you explain how you found those issues, as some of them are just plain wrong. It also contains lots of unrelated changes.
updated to something simple like unused variable. Direct return is something to consider later on as in this case its quite "complex". |
impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelObjectPool.java
Show resolved
Hide resolved
impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelObjectPool.java
Show resolved
Hide resolved
impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelObjectPool.java
Show resolved
Hide resolved
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.
2 ct.
impl/maven-impl/src/main/java/org/apache/maven/impl/DefaultSettingsBuilder.java
Show resolved
Hide resolved
impl/maven-impl/src/main/java/org/apache/maven/impl/DefaultSettingsBuilder.java
Outdated
Show resolved
Hide resolved
impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelObjectPool.java
Show resolved
Hide resolved
impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelObjectPool.java
Outdated
Show resolved
Hide resolved
impl/maven-impl/src/main/java/org/apache/maven/impl/model/DefaultModelObjectPool.java
Outdated
Show resolved
Hide resolved
src = Interpolator.chain(userProperties::get, systemProperties::get); | ||
} | ||
return new DefSettingsTransformer(value -> value != null ? interpolator.interpolate(value, src) : null) | ||
private Settings interpolate(Settings settings, SettingsBuilderRequest request) { |
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.
Once again, those are not unused variables. These are intermediary results.
Your refactoring hinders readability.
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.
ppl wondering just like the SCA why its unused or ignored. Having it named accordingly or removed seems to be the best practise in order to turn the questions into answers, as history is mystery.
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.
ppl wondering just like the SCA why its unused or ignored. Having it named accordingly or removed seems to be the best practise in order to turn the questions into answers, as history is mystery.
best practice is to understand what you are refactoring instead of blindly trusting tools/AI
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.
One could argue that "understanding" is a complex goal for this codebase. The presence of incorrect, ignored, and unused segments suggests that the original intent has become obscured over time. It's likely the logic was once valid, but that context has been lost.
The system continues to operate, but its current behavior appears disconnected from its actual purpose, seemingly functioning through emergent coincidence rather than by explicit design (no unused stuff dangling around).
In these situations, static code analysis becomes a valuable tool for reconstructing the rationale behind the code. As team members move on, institutional knowledge fades, and manual auditing does not scale effectively.
From my perspective, comprehending the full scope is challenging. For instance, the purpose of an unused field isn't clear, requiring me to hypothesize about its original function.
Ideally, code should narrate its purpose like a coherent story, with each line building upon the last. Gaps in this narrative—such as unused components or logical inconsistencies—highlight areas where the underlying purpose has been lost. While there may be valid, albeit hidden, reasons for these anomalies, the process of understanding involves methodically converting these open questions into resolved answers to piece together the complete picture.
impl/maven-xml/src/main/java/org/apache/maven/internal/xml/XmlNodeImpl.java
Show resolved
Hide resolved
dfa71eb
to
9b9f1c6
Compare
compat/maven-model/src/test/java/org/apache/maven/model/v4/ModelXmlTest.java
Outdated
Show resolved
Hide resolved
9c45a03
to
80c922b
Compare
impl/maven-xml/src/main/java/org/apache/maven/internal/xml/XmlNodeImpl.java
Show resolved
Hide resolved
api/maven-api-xml/src/main/java/org/apache/maven/api/xml/XmlNode.java
Outdated
Show resolved
Hide resolved
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.
public by default.
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.
This PR has, once again, derailed.
It contains changes which have nothing in common.
Please split PR:
- one for the
"""
string blocks, but maybe look at the whole codebase where it makes sense - one for
XmlNode.toString
refactoring - one for removing unused variables (but without any other refactoring)
Following this checklist to help us incorporate your
contribution quickly and easily:
Note that commits might be squashed by a maintainer on merge.
This may not always be possible but is a best-practice.
mvn verify
to make sure basic checks pass.A more thorough check will be performed on your pull request automatically.
If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
enabler for:
UnusedVariable
maven-parent#508related to:
ConstantNaming
diffplug/spotless#2687