Conversation
gnodet
left a comment
There was a problem hiding this comment.
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". |
| 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.
Once again, those are not unused variables. These are intermediary results.
Your refactoring hinders readability.
There was a problem hiding this comment.
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.
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.
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.
dfa71eb to
9b9f1c6
Compare
9c45a03 to
80c922b
Compare
Pankraz76
left a comment
There was a problem hiding this comment.
public by default.
gnodet
left a comment
There was a problem hiding this comment.
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.toStringrefactoring - one for removing unused variables (but without any other refactoring)
|
reopen once considering. |
|
The problem is that the build was failing IIRC. |
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 verifyto 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:
UnusedVariablemaven-parent#508related to:
ConstantNamingdiffplug/spotless#2687