I generally agree
with Lars and Alex as long as the clean-up is really improving the code
(performance, readability, etc.). I would turn down clean-ups that just
change the code based on personal taste.
In the actual
case I agree with the change for two reasons:
1. It is easier
to read (yes, personal opinion/taste). 2. In many cases
#isEmpty() is faster.
Loskutov" <loskutov@xxxxxx> To:
Should we accept any patches to attract more contributors? Sent
At the end I was asked to bring the issue "how/what the project should
value more" to PMC. I guess Alex wanted to ask is we should not "down vote" patches
to have more contributors.
My point on the gerrit was that mass change patches without functional
changes (or with questionable changes) are not acceptable because they
make code maintenance harder due broken git blame. I've made this -2 and -1 not because it is a matter of taste from me, which
code style is better or not, but because code maintenance is also about
understanding the history of the code, which is interrupted forever by
such mass changes.
I observe the results of such patches in Platform UI project, which had
numerous *non-functional* "code cleanups" behind it and now it
is impossible to use git blame on affected code. So all what I want is just to keep git history clean from non functional
mass changes. I do not see how accepting non functional mass changes can
attract more people.