Hi Antonio,
On 29.01.23 09:26, Antonio wrote:
Hi Michael,
Refactoring the code because of aesthetic, academic or modernization
reasons is a non-ending task in a >500KLOC codebase that will turn 27
this year. By the time we end up modernizing all the code it will then
be outdated.
Yes, project wide refactoring should be discussed, I am also not willing
to merge any stylistic or no-benefit change sets myself, since its just
noise and disturbs scenarios where git blame is used to reconstruct code
history. A PR needs to have a clear purpose and benefit - not all will
be merged.
Luckily, the amount of project wide inspections a dusty project *should*
run is finite. One example for it is having @Override used across the
codebase - this really is a low hanging fruit - the only reason I
haven't run this refactoring myself yet is because i wanted to write a
hint which ignores compact lambda candidates to shrink the change set.
There are also some "wrong-method" situations which can be fixed this
way, for example:
https://github.com/apache/netbeans/pull/3724
This is not only measurably faster and safer, this even fixed a small
bug (possibly more) - although not trivial to review since you have to
check every case - which I did.
IMHO we need contributors that are conscious of the implications of
the changes they propose, that run this extra mile that requires
thinking and explaining us the pros and cons, and the value they want
to add to the project.
agreed.
IMHO it's our responsibility to request these explanations to
contributors, otherwise we'll end up stuck in a never-ending loop of
reviewing a codebase that will turn 27 this year. These discussions,
as you say, should be done in the mailing list, and not in a PR
_after_ the code has been submitted.
agreed. Although as mentioned above, I believe the code inspections old
code bases should run are in fact finite. Projects like OpenJDK do run
them too periodically.
best regards,
-mbien
Cheers,
Antonio
On 27/1/23 17:42, Michael Bien wrote:
[...]
Another example are generics, which is super tiresome to review -
this has to be split up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
