30
\$\begingroup\$

Every now and then, I see an edit where somebody does some golfing (most recent). From what I can tell, our standard is to reject those edits as invalid and post a comment saying what was suggested, because we feel that golfing tips should be comments. And I have always done so (after I learned).

However, some edits are very small, such as the one I linked to. If I can determine that they are correct, is it appropriate to approve them?

What type of golfing edits should we approve?

\$\endgroup\$
  • 11
    \$\begingroup\$ The problem with suggested code edits here is the same as on SO: reviewers need expertise in a certain language before they approve. Also, it's a really good idea to test before any edit. Do we expect reviewers to do so? \$\endgroup\$ – John Dvorak May 23 '14 at 7:33
38
\$\begingroup\$

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.

\$\endgroup\$
26
\$\begingroup\$

Users should not edit code by other users. Even if an edit seems correct, it might not work with the original computer. Golfers like to make nonportable assumptions which are not true with every platform, or with every version of a programming language.

Suppose I write sed(1) regular expression /[0-9][0-9]*/, matching one or more digits. Another user wants to golf this into /[0-9]\+/, but I disagree, because my sed(1) doesn't have \+.

Here is a real example: I wrote a Unix shell program xmessage -timeout 3 hello world in 31 characters. A comment suggested timeout 3 xmessage hello world in 30 characters, but I said no, because my computer had no timeout command. I like such comments, but I want users to post them as comments, not by editing my post.

\$\endgroup\$
  • 1
    \$\begingroup\$ Agreed. I don't want someone else changing or golfing my answers for me. They're my answers, and if other people can edit them for golfing purposes, it would no longer feel like it's my answer. That, or I could come back after a couple days and suddenly my answer has been golfed and I no longer understand the code. \$\endgroup\$ – mbomb007 Jan 19 '17 at 22:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .