For whatever reason, it would appear that users with under 2000 rep are strongly discouraged from making suggested edits to code blocks even in answers:

These are only the users who felt strongly enough about their code edits to come to meta and post here. There are likely many other users out there who get their edits rejected and don't both posting about it on meta at all, assuming that somehow they made the wrong decision as dictated by the community rejection of their edit.

My personal belief is that these sorts of edits should be encouraged, as explained in the help center:

Posts are Intended to be Collaboratively Edited

Editing is important for keeping questions and answers clear, relevant, and up-to-date. If you are not comfortable with the idea of your contributions being collaboratively edited by other trusted users, this may not be the site for you.

Edits should correct mistakes

Edits are expected to be substantial and to leave the post better than you found it. Common reasons for edits include:

  • To fix grammar and spelling mistakes
  • To clarify the meaning of the post (without changing that meaning)
  • To include additional information only found in comments, so all of the information relevant to the post is contained in one place
  • To correct minor mistakes or add updates as the post ages
  • To add related resources or hyperlinks

In an ideal world, edits under 6 characters would be allowed and reviewers wouldn't reject those edits because they were worried about future audits or because they think fixing non-working code fundamentally changes the answer. It would be awesome if editors could make a simple edit rather than expecting them to make a comment, followed-up by a separate answer if the comment isn't implemented. But we don't have an ideal world.

So rather than subjecting users who want to contribute positively to the quality of answers on this site by fixing broken answers to rejection, we should restrict editors with less than 2000 reputation from touching code blocks altogether and save them the headaches it causes.

(Whatever changes are made, any and the Help Center should be updated to reflect what the policy is to prevent confusion from anyone who actually bothers to read them and wonder why the reality on the ground doesn't match those guidelines at all)

Note: I am not suggesting that suggested edits cannot add code to a post (for instance, by adding code markdown to code formatted as plain text), only that code that is already formatted as code should not be able to be edited by users with under 2000 rep.

  • You don't like how hastily reviewers reject code edits. This proposal will stop those rejections because there won't be any such edits to review anymore. Today, people ask why their edits are rejected. If this proposal takes effect, I think they'll instead ask why they weren't allowed to submit their edits. That is, the questions keep coming on Meta, and mistakes in code remain unfixed, so there's no net gain. Why not a proposal influencing reviewer behavior? Oct 10, 2013 at 5:10
  • 9
    I never use '<pre>' Oct 10, 2013 at 5:33
  • 1
    @Rob, you could add a nice box explaining 'you cannot edit code blocks until you have 2000 reputation' if they try. This could link to the privileges page for editing, or to the edit entry in the help center. I would rather have editors not be discouraged early than to have their good edits rejected. As you pointed out, I do support the other proposal, which already has a feature request on it. I could make another I suppose.
    – jmac
    Oct 10, 2013 at 5:45
  • @Andrew, while probably a joke, <pre></pre> is what you get when you hit Ctrl+K or click the code button. <code></code> is what you get when you add backticks around something.
    – jmac
    Oct 10, 2013 at 6:54
  • Edits are done to the markdown; not to the resulting HTML. Oct 10, 2013 at 6:56
  • While I am no developer, I would wager that if you can parse the markdown to generate HTML, you can determine which portions of the markdown would end up in <pre></pre> tags in the resulting HTML, and prevent their editing in the markdown.
    – jmac
    Oct 10, 2013 at 6:58
  • 1
    I very often edit or add code that new(er) users don't edit into their own question for clarity reasons, and I don't even have 200 rep. Only three of my edits have been rejected and that was because somebody else edited them in the same way around the same time. If an edit is less then 6 characters, you should just comment on the post informing them an edit is required...
    – Amber
    Oct 10, 2013 at 9:09
  • 2
    @Amber, just read through all your edits and didn't see one where you are editing code for syntax (in other words, making corrections to code). You are usually adding proper formatting where there was none, or adding content from the comments where there was none. None of these would be prohibited by my suggestion. (And contrary to my post, I think that what you're doing is awesome and should be encouraged -- you just aren't getting rejects because you aren't changing code itself)
    – jmac
    Oct 10, 2013 at 10:17
  • Changing formatting of code is a very important kind of edit, changing the code itself is far more dangerous. Oct 10, 2013 at 15:05
  • @Codes, where does 'format' end and 'changing code' begin? Some languages change dramatically based on formatting and white space, so any change to code has to be given a careful review. If this is dangerous, you should support this feature-request to prevent edits from happening.
    – jmac
    Oct 10, 2013 at 23:24

3 Answers 3


Please do not follow incorrect guidance given on Meta Stack Overflow. Users with under 2000 reputation are NOT discouraged from making suggested edits to code blocks in answers.

The rules for editing are given in the editing help.

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 correct minor mistakes or add updates as the post ages
  • (…)

The short introduction to Stack Exchange mentions edits:

Our goal is to have the best answers to every question, so if you see questions or answers that can be improved, you can edit them.

Use edits to fix mistakes, improve formatting, or clarify the meaning of a post.

There is absolutely no reason to prevent people from fixing mistakes in certain parts of a post just because that happens to be code.

It is usually incorrect to change code in questions, because if you fix the problem that the question was about, this removes the object of the question. There is no reason to change code in an answer: if the answer is mostly correct but contains minor errors, in code or elsewhere, it is correct and encouraged to fix them.

Users without the edit privilege (less than 2000 reputation) are requested not to make edits that are too minor, because each suggested edit also costs reviewer time. An edit that corrects a mistake is by definition not too minor.

The right way to resolve the conflict between the official rules and the bad reviewers is to fix the reviewers' behavior, not to change the rules, because the rules are there for a good reason: they make the site better. To encourage leaving errors in posts would make the site worse.

  • Totally agree. To sum it up, I personally approve syntax error fixes for code in answers as long as it's not changing its logic. Oct 10, 2013 at 9:00
  • I totally agree as well, but all the other threads suggesting these edits should be approved get shot down for various nonsensical reasons. I agree that they should be edited, and accepted, but the reality is that they are denied and causing new users grief. I would rather have users denied a privilege and not be slighted than to be told one thing and then shown the opposite.
    – jmac
    Oct 10, 2013 at 10:11
  • (The entire original post is truly tongue in cheek, in the sense that I think the suggestion is absurd beyond belief, yet the only alternative people offer to suggestions like this is "have new users make comments, and then follow-up with separate answers correcting the mistake if it's ignored". I hope that the juxtaposition of what the rules say, and what people suggest new users do wakes up a few souls who care about site quality and common sense, like you Gilles, though you didn't need waking up)
    – jmac
    Oct 10, 2013 at 10:13
  • @jmac I realize that you disagree with your suggestion, but I'm afraid your post doesn't work well as a wake-up call. Witness Makoto's answer, which completely misses the point. I don't think the people who need the wake-up call will understand. Oct 10, 2013 at 10:58
  • "An edit that corrects a mistake is by definition not too minor." This is not true. An edit that corrects a mistake and leaves fifty others in place is too minor. Oct 10, 2013 at 14:33
  • @Gilles, I tried to summarize this in a faq-proposed post here. I would appreciate your input as well!
    – jmac
    Oct 11, 2013 at 1:49

There are cases in which editing code is okay.

This is most notably (and infamously) in the formatting of code blocks, or at least, improving readability. If absolutely nothing else needs to be improved in the question, these sorts of reviews give me the least heartburn.

Disallowing one to edit code blocks sounds silly, if only for the above.

There are cases in which editing code is not okay.

Any edit to code that changes semantics - namely, code that uses a newer library, a newer programming technique, or heck - even an edit that makes the code snippet compile, is invalid in my mind.

Here's why.

  • Any change in a question's semantics may lead to inappropriate answers. For instance, if the question is based in Python, and whitespace is added to the question the improve readability, we've lost context into what the real problem might be.

    It could also be the case that a question is using a deprecated library, or class that doesn't exist. If those are edited out, then the context of the problem is lost.

  • Any change in an answer's semantics may lead to an invalid answer. Even if it's merely correcting syntax as to make it compile, that still feels invalid.

But, the best part here is:

Your definition of "minor" is subjective.

Take, for example, the suggested edit that you indirectly linked to. I'll put this out as a disclaimer - I don't know C#, but I'm willing to bet that a Message object is different in some way to a MessageBox. If I saw this edit without paying close attention to context, and it were in a language I understood (so as to gain deeper insight into my decision), I'd reject it on sight.

If you personally feel that the code is wrong, or that there is an error, comment. If the post is outdated, answer it yourself with a newer code snippet. Merely editing the bad code ourselves feels inappropriate - I'd rather involve the original poster and explain to them why their code is invalid, or what syntax errors they've made - and leave appropriate voting feedback on their question/answer.

There are differing schools of thought on this, as well. I recall hearing a Stack Exchange podcast in which some users had strong opinions on the matter, but ultimately felt that this was an okay thing to do. It's apparent to me that there are some disagreements in protocol, but there are some that think that editing questions/answers with newer code is acceptable.

Now, this isn't to say that I, as a reviewer, would blanket-reject any code syntax change. I have to look at the question in earnest and see if the semantics have been violated in any way. If I feel that they are, I would then suggest that the editor make an answer of their own instead.

Of course, this is all my own opinion. Other reviewers do it differently than I do. And that's not a bad thing.

  • 2
    In some programming languages, white space or carriage returns for 'readability' could affect the functioning of the code. Even the simple cleanup/readability stuff requires diligence on the part of reviewers. Regardless, asking people to make a comment leaves a class of people (under 50 reputation) unable to participate, and doesn't match the help center on what a comment should be, or the help center on what an edit should be. There is a gap between what a user should do, and what a user is told to do, and my suggestion is to eliminate the confusion by eliminating the privilege.
    – jmac
    Oct 10, 2013 at 6:56
  • 2
    As user without 50 rep, I'd post a new answer, linking the original answer (or at least mention it), explain the mistakes there and provide a correct answer. Note that your answer should be able to stand alone, because the original answer might be deleted by it's owner. Use quotes. Oct 10, 2013 at 7:50
  • 3
    Your answer contradicts the official rules. This is not just a matter of differing schools of thought. “To correct minor mistakes or add updates as the post ages” is a valid and encouraged reason for editing. Oct 10, 2013 at 8:56
  • 1
    @Johannes, you are a user with 3.5k rep. You know what the rules are. Assuming that a new user will jump through said hoops despite the site guidelines suggesting an edit as Gilles points out doesn't make much sense. Why do people want to make this complicated? If you want to make edits so complex that new users can't make them, then just deny them the ability. If you want them to make these comments, then allow them to edit using the existing system. This "jump through fire and we may accept it" stance isn't realistic.
    – jmac
    Oct 10, 2013 at 10:09
  • @Gilles: Perhaps we're misunderstanding each other. When I think of a minor edit to a code block, I'm thinking formatting changes. Changing the code otherwise changes the meaning - which is also spelled out in the official rules. And perhaps I'm incorrect in my assertions; I'll look at code changes with a closer eye from now on. Yet, your answer and comment haven't yet demonstrated that I'm completely in the wrong here. I can accept if I'm in the wrong.
    – Makoto
    Oct 10, 2013 at 20:22
  • 1
    @Makoto Some examples of “minor mistakes” in a code sample would be a misspelled variable name or a missing argument to a function. Correcting such minor mistakes is encouraged. “Changing the meaning” (I dislike this expression, because it's interpreted in all kinds of nonsensical way) would be for example replacing the code by a different algorithm. Oct 10, 2013 at 20:47
  • I think where we're differing is when these edits should apply. I'm firmly opposed to code fixes to a question. I'll examine code fixes to an answer on a case-by-case basis, although I feel if the algorithm does get wildly changed, then it's a "reject" vote from me, and I'd explain that they should add their own answer instead. The FAQ that @jmac posted up is one that I largely agree with, and despite it not coming across as such, I believe I'm agreeing with much of what's being said here.
    – Makoto
    Oct 11, 2013 at 2:40
  • @Makoto, I totally agree on code changes to questions (as you can see from the related faq-proposed post, it is the answers where we differ. Anyway, as you've already commented on the other one, you can suggest edits over there to find a happy way we can get better quality stuff.
    – jmac
    Oct 11, 2013 at 2:52

And again a discussion what suggested edits should be allowed.

I tried once to make a poll about exactly this, but it leads to the deletion of the question. Well, polls are not exactly the best thing for Q&A.

For code changes, there are only a few options:

  • Reject every code change except whitespace in a whitespace tolerant language.
    The change between a working and a broken answer is quite big. Reject as invalid edit (user should post an own answer) or radical change.
  • Allow fixes of the code, but not a different approach
    The reviewers have to know the language. If you don't know it, skip it; robo-reviewers accept/reject it anyway.

    Example: someone posted this piece of code in :

    if $var {...}

    Someone changes it to

    if {$var} {...}

    Although the second form is the prefered one, there is a subtile difference.

    So we could change the review queue so you need a certain score in one of the tags to review, but this would defeat simple grammar/spelling changes.

  • Allow anything and close the review queue.

For me, the only vitable option is to reject every code change. As Bart said:

The consensus is to not change code. Not even to fix it. So in this case the rejection was fine and expertise within the tag is not necessary. Leave a comment for the author to point out the issue. He can then fix it.

Gilles athough says:

Your answer contradicts the official rules. This is not just a matter of differing schools of thought. “To correct minor mistakes or add updates as the post ages” is a valid and encouraged reason for editing.

But always remember that:

[Stack Overflow ... is] built and run by you

You must log in to answer this question.

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