I have noticed the same thing. Personally I disagree with code edits, but I would like to know what others think..
Personal anecdote
Recently I have received many useful suggestions in comments, some of which have been wrong. For example on this question https://codegolf.stackexchange.com/a/26330/15599 this user https://codegolf.stackexchange.com/users/12012/dennis suggested in the comments that the following code could be contracted thus by changing from logical and
to bitwise and
:
while(p-h&&p-w) -----> while(p-h&p-w)
This does not work, because I want to exit the loop when p is equal to h or w, and with the suggestion it would exit early for example with p=3, h=1, w=2
The user quickly realised his mistake and deleted the comment, but went on to make several helpful suggestions that significantly reduced the code, always being respectful enough to make his suggestions via comments and allowing me to test the suggestions for myself before incorporating them (btw, he wasn't testing them himself, there was a typo in one suggestion.) I was also able to improve the code further on top of his suggestions, so the fact that he made the suggestions in the comments saved an unnecesary edit cycle. And I learned more that way, too.
I appreciated this user's input, but would have been annoyed if he had made direct edits (especially untested ones) on my code without asking.
And I actually had to download a different compiler to take advantage of certain suggestions. See here: https://codegolf.stackexchange.com/a/2204/15599
Conclusion
I generally reject or skip code edits when I see them in the review queue. If there is a strong agreement here, I will change to always rejecting.
One of the first examples I saw I rejected but it got accepted anyway. But I have seen other edits accepted that most definitely should have been rejected that got through (one user added some irrelevant tags, and admitted afterwards that he had made a mistake because he "thought he was on another question.") Therefore as a general point, always think before you click accept
, and if unsure click skip
Somebody has to test that revised code, and really that should be the answer poster. The suggester may have tested, but what works on your machine may not work on mine, and the answer poster will presumably want code that works on their own machine. The reviewer should also be very sure the code will work (which may involve testing, but as Jan Dvorak points out that is a lot to ask.)
I have only accepted one code edit, and it was because the answerer had included some imports
in the golfed version but not in the ungolfed version. I considered this a formatting edit rather than a code edit, so on this one occasion I accepted it.