What is the policy of editing code in answers?

Question

Do I feel too much "ownership" of my answers, if I feel that people should not edit the code in an answer merely to make it shorter/more in tune with their own coding style/preferences?

If the code has a syntax problem, spelling error in a comment, or something like that, it makes sense to me to edit code in another persons answer, but just rewriting the code to "be shorter" seems a little excessive to me.

Can I "disown" an answer where the code has been changed enough by someone, for me to no longer feel connected to the content of it?

(In the particular case that spurred this question, I just resorted to deleting my answer, as I did not want my name associated with the changed code snippet.)

Answer 1

I feel that editing code in answers should be avoided where possible. Fixing syntax or spelling errors is fine but actually changing to code, be it to shorten or to use a different style, feels as though it should almost be an indepent answer (showing alternative methods).

The only partial exception I could envision is if the code in question makes use of third-party libraries (dash.el,s.el and the like) where built-in functions are equally effective. In those cases I could see adding an additional block showing how to perform the equivalent so as not to require a library that the user might not have installed[1].

As an example, this answer uses --each to iterate over a list of modes, which could also be done with mapc or dolist.

[1] This is not the same as suggesting a package to provide a feature.

Answer 2

There are basic rules about editing in the help center. Quoting the relevant parts:

When should I edit posts?

Any time you see a post that needs improvement and are inclined to suggest an edit, you are welcome to do so. (…) Common reasons for edits include:

• To fix grammar and spelling mistakes
• To correct minor mistakes or add updates as the post ages

When it comes to code, do fix simple syntax or logic errors. The basic idea is that you should try to make the post be the way the original author intended. Usually the original author intended the code to work, so if you notice what is clearly an error, fix it. This includes missing parentheses, typos in variable names, missing arguments to a function, etc.

Do respect the author's style. For example, don't go and change the original author's variable naming conventions. Don't rewrite the code using a completely different package.

General rules can't cover every case. For example, removing a dependency on a third-party library or recent version of Emacs can be a good thing if it affects a tiny part of the code, or a bad thing if it requires a complete rewrite of a function. Use common sense.

In all but a narrow set of circumstances, the original author gets the last word. (Exceptions include adding attribution for non-original content, and egregiously dangerous advice that warrants a clear warning.) If the original author rolls back your edit, move on. If you really don't like the author's version, you can downvote (if a post has been edited, you can change your vote on it). If you think your edit matters, you may want to post an answer of your own, giving credit to the original author if you copied part of their code.

As an author, if someone makes an edit that you don't like, roll it back. You may leave a comment to the editor to explain why you didn't like the edit; if you write @name-of-editor in a comment, the editor will receive a notification, even though the interface doesn't provide completion for editor names. Don't get into a rollback war: if the editor insists, flag for a moderator's attention and explain what is going on.

Don't delete your post because you didn't like someone's edits. Your post is still your own. Moderators may undelete self-deleted answers if they feel that the answer was useful — we don't like it when people take their marbles and go home.

Answer 3

Straight away, changes for stylistic reasons are not helpful.

Changes to fix errors or bugs in the code should be allowed. Things like "this no longer works", or to fix an edge case fall into this category.

If someone has an alternate method or strategy to solve the same problem, that should be posted as a new answer, not edited into an existing answer.

Answer 4

I think that code should be edited to fix obvious errors. Additionally, I think it's generally acceptable to edit code to fix idiomatic mistakes, or replace discouraged idioms or bad practices.

For instance, a frequent pattern is to compare against point, e.g. (< (point) (point-max)) or (eq (point) (line-end-position)). This is recommended against, because it is inefficient. Rather you should use intrinsic functions, e.g. (not (eobp)) or (eolp), and I think it's acceptable to edit answers accordingly. We should not let bad practices sneak into answers.

Stylistic edits however are too much, in my opinion. None should edit answers to replace cond with pcase just because they like pattern matching…

In any case, if you don't like an edit, ask for clarification in comments, or revert the edits. It's your answer, after all.

Answer 5

On stackoverflow, I regularly make small changes to people's code, always to fix discouraged idioms. In 99% of the cases it's to replace a '(lambda ..) with (lambda ..) since quoting lambdas is generally a bad idea (and is incompatible with lexical-binding, which I'd like to encourage), and the only reason people do it is because they see it in other people's code. Pointing out the problem in a comment is not sufficient, since people will still see the quoted lambda and may overlook the comment.

So, I think it's important for us to accept such changes (BTW, currently, it looks like emacs.stackexchange rejects them because they don't change less than N characters :-( ). But I do agree that changes to other people's code should be limited to fixing such minor problems.