The Help Center has a nice section titled "When should I edit posts?". It comes with a couple of helpful editing suggestions.

What is not made clear in there however is when/what you shouldn't edit. I would propose a small addition to the help center, primarily motivated by some of the comments made here:

Is there anything I shouldn't edit?

When it comes to questions, don't change the code. Minor code formatting and indentation corrections are often acceptable, but for indentation sensitive languages such as Python, even such edits are best not made. Correcting what you think are typos or irrelevant mistakes might well change the entire question or confuse the author.

Editing code in answers follows roughly similar guidelines, though the correction of an obvious typo is often acceptable. If your edit is substantial however, it is often wise to leave a comment for the author explaining the flaw and requesting the correction.

Of course the wording is merely a proposal and I would be open to other suggestions and improvements.

I think such a clarification would be good information to have for suggested edits, and it would perhaps prevent some of the "Why was my edit rejected?" questions we see here on Meta. (One can only hope). Particularly so when the information tells you to "correct minor mistakes".

  • How about the edge cases: A) the author has been absent from SO for a long time (say, 6 months); B) the author actually asked the user to edit his post? Commented Jul 5, 2013 at 10:24
  • 2
    @doubleDown That would diverge this request into a discussion of what's an acceptable edit... Yes there are edge cases. And you'll pick some of them up the more your participate here and the more privileges you gain. But I think the Help Center reflecting the general case is not a bad thing.
    – Bart
    Commented Jul 5, 2013 at 10:27
  • +1 because yeah, that would help people reading the FAQ (or at least me :P) to write better edits, or to not write them when they shouldn't.
    – Xaqq
    Commented Jul 5, 2013 at 12:12
  • 1
    And it would give us a stick to beat users with @Xaqq...ehm...documentation to gently point mistaken users at, I mean.....stick? What stick? :)
    – Bart
    Commented Jul 5, 2013 at 12:27
  • 5
    "Do not use backticks when editing. Ever." Commented Jul 5, 2013 at 13:39
  • Unless you want to highlight things of course @BoltClock'saUnicorn? /me runs and hides
    – Bart
    Commented Jul 5, 2013 at 13:51
  • Note to self, stackoverflow.com/questions/17589260/… for use in proposal
    – user310756
    Commented Jul 11, 2013 at 9:54
  • Are you serious, these people just want to rack up edit suggestions and edit reviews... stackoverflow.com/questions/17590288/… OH the curse of being pedantic!!!!!!!!!!
    – user310756
    Commented Jul 11, 2013 at 9:55
  • @bart yes, I have felt that stick, and I love how you handle disagreement re Boltcock's backticks.. this is hilarious.. thnx for the laugh guys :)
    – user310756
    Commented Jul 11, 2013 at 10:00
  • @BoltClock'saUnicorn Sorry, why? I can't even tell if you're being serious or joking. What am I missing?
    – Mark Amery
    Commented Jul 27, 2013 at 8:26
  • @Mark Amery: Only half-serious. At least on Stack Overflow, we have a plague of backtick abuse in edits, so I'd rather people just stop using them unless they knew what they were doing. But again, only half-serious - there are appropriate uses for backticks. Commented Jul 27, 2013 at 8:29
  • @MarkAmery My comment following BoltClock's more or less indicates what people tend to use them for.
    – Bart
    Commented Jul 27, 2013 at 8:31
  • @BoltClock'saUnicorn Do you mean that people aren’t using backticks for monospace code but rather for regular text that should simply be italic for emphasis, or maybe bold, instead? Could you please give some links to examples of such?
    – tchrist
    Commented Jul 27, 2013 at 17:31
  • @tchrist: Here's one: meta.stackexchange.com/questions/135112/… There's a constant supply of them in Stack Overflow's suggested edit queue as well. Commented Jul 27, 2013 at 17:34
  • @BoltClock'saUnicorn Freaky! No, that just isn’t right. Weirdos! :)
    – tchrist
    Commented Jul 27, 2013 at 17:36

4 Answers 4


In general, enumerating badness is a bad idea... Particularly when it comes to something that like editing that depends heavily on context. If you're going try and warn against certain behaviors, you want a few specific, easy-to-recognize examples that the reader can extrapolate from, not a complicated set of prohibitions that must be carefully parsed before it can ever be applied.

The guidance you've written appears to disallow a vast swath of useful edits in favor of those that can be reviewed without any knowledge of the subject. But such edits are already a source of frustration - I see no reason to go any further to encourage more context-insensitive rejections... or more timid, superficial edits.

Should you be extra-careful when editing code? Yes, absolutely. In particular, if you don't have a solid understanding of the language you're working with in general and the specific code being edited in particular, tread lightly.

But presuming that all or even most editors on a site for programmers won't have a clue how to edit code seems... Unreasonably pessimistic. Particularly when it's so easy to correct mistakes.

Worse yet, this guidance directly conflicts with the guidance already on the page, which suggests editing...

  • 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

Shall we abandon all hope of moving useful information from transient comments into permanent, searchable posts out of fear that someone will screw it up? Shall we relegate updates to old posts, their authors long ago moved on, to comments pleading futily for permission to edit?

The problem you're identifying is largely limited to suggested edits - so let's focus on that. We already have an official set of guidelines for rejecting these:

edit reject reasons

Not only are these displayed to every reviewer, they become attached to the suggested edit itself, providing an edit-specific explanation for the rejection. They haven't been updated in quite a while either, and could almost certainly use some work...

With some form of editor notification implemented, this would likely go a lot further toward your goal of reducing support request here on Meta than a couple of paragraphs buried in the help center.

  • 2
    Agree completely. Not only is the general sentiment here against making any useful edits besides typo corrects and code formatting improvements, but it even explicitly discourages some of the most useful them (like cleaning up indentation in a poorly copied-and-pasted code block in a Python question). I don't know how to write good general guidance on when and how to edit, but I'm not a fan of Bart's attempt here.
    – Mark Amery
    Commented Jul 27, 2013 at 8:15
  • 3
    And breath.... should you be more careful when editing code in answers? Sure. Are users? Not really. (I know, I know, I should back this up with example edits and the like.) Should reviewers only accept them when they are correct? Sure. Will they? Not really. Feel free to reword my proposed text if parts of it offend you. It's a mere proposal. But if nothing even states that code edits are deemed problematic, we shouldn't be surprised they happen, that they happen poorly, and that we have Meta users wondering why they got rejected.
    – Bart
    Commented Jul 27, 2013 at 8:37
  • @MarkAmery If there is a case of poorly copy-and-pasted Python code, in an answer, which is otherwise correct except for the indentation, I would have no problem with the edit. If we're talking about a question however, the indentation might be well part of the original problem.
    – Bart
    Commented Jul 27, 2013 at 8:39
  • 4
    Heck @Shog9, you can even turn it around. Add it to the "When should I edit posts" section. Make it a "Tread with care" advice. You could give advice along similar lines, but perhaps that's a more positive and less excluding angle. But to say nothing is, IMO, not the way.
    – Bart
    Commented Jul 27, 2013 at 8:53
  • 4
    I agree with 99% of this. My only concern is that I see a fair number of suggested edits that "fix" code in questions. Their edits are certainly correct from a compiler's perspective, but they're inappropriate because they obscure the question itself. Even if the edits are not to things fundamental to the question, good answers will often comment on other problems. The edits make those answers confusing nonsense. Commented Jul 27, 2013 at 9:19
  • 1
    I've also seen a fair number of suggested edits that make questions easier to read and understand by fixing irrelevant errors, @Cody - as Mark notes in his answer, the guidance suggested here, though perhaps written with the best of intentions, explicitly warns against changes that are all but essential. If anything, we need better guidance (and canned reject reasons) for reviewers - if we're currently encouraging worthless formatting changes over helpful code-cleanup, then that's a much bigger problem.
    – Shog9
    Commented Jul 27, 2013 at 16:18
  • I'm assuming you're purely referencing answer edits here @Shog9? If you want to encourage code improvements (which you might then have to inform the community about, because the consensus seems to be different) then at least let that go hand in hand with a better targeting of reviewers. That would leave the issue of editing code in questions. Or do you object to saying anything about that in the Help Center as well?
    – Bart
    Commented Jul 27, 2013 at 17:35
  • Please refer to Mark's answer, @Bart. I've many times "fixed" typos in questions that were clearly describing a problem that had no connection to the error being fixed. Missing braces, semicolons, unescaped angle brackets, misspelled classnames... In particular, if you're answering the question it's probably fairly obvious to you what the problem isn't.
    – Shog9
    Commented Jul 27, 2013 at 17:38
  • That's pretty shaky ground you're treading upon then. If you're answering, you might have a reasonable idea. But not all editors are answerers. Some are editors for editing sake. And where is the line? Code edits arguably require even more editing and reviewing expertise than formatting changes or even spelling corrections. Especially where they become non-trivial. And how do you deal with the situation where you essentially say "Sure, code edits are fine if they make proper corrections" yet the editors find them rejected by the community in some unwritten form of consensus?
    – Bart
    Commented Jul 27, 2013 at 17:53
  • 1
    "Editors for editing sake" @Bart? Is that a euphemism for something? Anyway, the hard line would boil down to fundamentally changing the nature of the question - and sometimes, finding that line requires you to know something about what you're reading/editing. Does this make life harder for reviewers and provide fewer guarantees for those without full editing rights? Heck yeah! But remember, we do have a fairly sizable population of editors with full editing rights too.
    – Shog9
    Commented Jul 27, 2013 at 22:02
  • Not a euphemism no. :) But we've all seen the poor edits which arguably are for rep or badges and which aren't up to scratch. And which subsequently get through because the review process has its flaws as well. And with code, that gets iffy pretty fast. I guess we'll have to agree to disagree to some extent. You seem to have more faith in the system than I do, and you arguably have the data to back it up with. (Not that I'm claiming the sky is falling down though) But thanks for your input anyway. Always appreciated. :)
    – Bart
    Commented Jul 27, 2013 at 22:29

Because the guidelines for editing and suggested editing are different and because what is considered acceptable to one community may not be acceptable to another, I think an expanded version of this idea would work better as a post under the tag. There is a post on reviewer guidelines (although not a yet), but doesn't quite answer the question for the editors completely enough.

Given the fact we get a lot of "why was this edit rejected" and similar posts on MSO (I can't speak for site specific metas as I don't frequent them as much), it would probably quality as a "frequently asked question" anyway. It would also give a good canonical post to link duplicates.

Placing it in the help center gives this an official rule feel, which I don't think it is. The guidelines for editing are decided more on community consensus instead, so a MSO post that would be more easily edited and allow it to grow and change organically as the rules evolve in time.

It would also allow for more detail as to what is consider acceptable and actually explain why, which I think it needed, rather than just 2 paragraphs that say "Don't do this". And a Shog points out, it does run contrary to other bullets on the same page.

As Bart points out though, a meta post will not get nearly the visibility as a help center entry, so I think the help center idea could be refined to link to a faq post. It would also help with transparency to Bart's other point of the Stonecutters Ancient Mystic Society of No Homers MSOer's trying to host it's own secret rules.

An addition to this page under the When should I edit posts? section could be the solution (emphasis is mine to highlight the addition):

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. The original author of a question or answer may always edit their own post, regardless of reputation level.

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

For more information on how editing works and suggestions on how to make good edits, please visit <some meta link>

In fact this idea could be expanded into a complete editing FAQ (probably best as a series of posts) which goes into details on all of the editing policies and guidelines.

  • The guidelines for editing and suggested editing are different? What are the differences, and where are they described?
    – Mark Amery
    Commented Jul 27, 2013 at 10:25
  • 1
    The problem with that though is that it only addresses the issue after the fact. I would be surprised if the majority of users read the FAQ entries on Meta. Heck, I would be surprised if the majority read the Help Center, but that's another issue. Sure, what you propose would be something. But it's all rather invisible for the regular user.
    – Bart
    Commented Jul 27, 2013 at 10:29
  • @MarkAmery I don't really have a link describing the differences. The idea though is what is considered acceptable for someone with full edit privileges may not be considered acceptable for a suggested edit. Current SO guidelines use suggested edits to encourage cleaning up grammar, formatting, and spelling, where full edit privilege users have more latitude. The idea behind my answer here to help explain the differences and why those differences exist. Commented Jul 27, 2013 at 10:36
  • 1
    @MarkAmery It would also let each community explain the editing guidelines in their own words without relying on a member of the community team to edit the help center as the guidelines for editing can vary so much from site to site (and change over time). Commented Jul 27, 2013 at 10:36
  • @Bart I agree that the help center idea would get slightly more visibility, but I just think the editing guidelines need more room to detail than can be covered in the help center. Maybe the help center could link to the faq so you get the best of both worlds. Commented Jul 27, 2013 at 10:39
  • That might be an idea. I remember a user accusing Meta of hosting its own set of secret rules in a sort of a secret society manner. Wouldn't want that to happen again. ;)
    – Bart
    Commented Jul 27, 2013 at 10:43

This is a bad idea for two reasons.

First and foremost, this adds some detailed rules about an uncommon case. The current guidelines for “When should I edit posts?” are 122 words long. You're proposing to add a whooping 100 more words, so the size of the rules would almost double. You need to keep these guidelines short and to the point, otherwise nobody will read them (as opposed to almost nobody).

The rule you propose for questions is a refinement of one of the already existing guidelines: “to clarify the meaning of the post (without changing that meaning)”. If a question is about a piece of code, this code shouldn't be changed in any way that changes the meaning of the question, which rules out most non-whitespace edits.

In my experience as a reviewer, edits that change the code in ways they shouldn't are exceedingly rare. It's not a case worth mentioning in generic guidelines. Among the vast number of bad edits, there are far, far, far more edits that scramble the formatting. If I could add one sentence to these guidelines, it would be “backticks are for code, not for emphasis or for proper names”.

In addition, the help section is the same on all sites; your proposed addition would have to be present only on Stack Overflow. While this is technically possible, it's likely that users who participate on multiple Stack Exchange sites would read that section only on one site, so they may never see this SO-specific content, or see it and be confused because it doesn't apply to other sites they edit on.

A second problem with your proposal is that the part about answers is not good advice. There is a major difference between editing code in questions and editing code in answers. In questions, when you go beyond indentation, there's a real chance that you'll inadvertently fix the problem that the poster was asking about. In answers, there is no such risk, and you should encourage editing answers to fix minor mistakes. Correcting the name of a method, adding a missing parameter, adding a missing validation condition, adding proper escaping to avoid code injection vulnerabilities, … Those are all good edits and should be encouraged. Stack Overflow already has a problem that many of these edits are wrongly rejected; we don't want to add anything that discourages such edits.

  • The proposed message is of course just that: a proposal. It could be rephrased in any more desirable way. But you make several good points, as did Shog. Perhaps it would be worth considering the other side: Say we take a more code-edit-friendly stance as a community, then what can we do to have better reviews. Accepting the odd bit of terrible formatting is nasty. But accepting wrong code is worse. As is the rejection of actual good corrections because of a lack of knowledge. But well, that's just me rambling off the top of my head a the moment. +1 anyway. Thanks for the input.
    – Bart
    Commented Aug 8, 2013 at 18:17
  • 1
    @Bart I'd rather err on the side of accepting edits that break the code than on the side of rejecting edits that correct the code. Edits that break the code can be corrected. If we never accept edits that correct the code, the code will stay wrong forever. Commented Aug 8, 2013 at 18:28

I totally disagree with the idea that correcting indentation in the code of a Python question shouldn't be allowed, and more generally I don't think it's true that you shouldn't correct mistakes in code in a question.

I think there are two points you kind of wanted to make when you said that, but you've been too aggressive and come up with an overly sweeping rule that discourages too much. I think you wanted to express the following points:

  • Obviously, if someone posts code saying "My code is throwing Exception XYZ - why, and how do I fix it?" then you shouldn't 'correct' the code to a version that doesn't throw Exception XYZ. More generally, you shouldn't fix the problems that are actually being discussed in the question.
  • You also shouldn't fix bugs or instances bad practice in question code that don't prevent the code from running or being understood, and which don't prevent the problem being asked about from being exhibited, although pointing such issues out in comments may be appropriate. (E.g. pointing out an SQL injection vulnerability in code posted for a question about something completely different is a good use of a comment, but you shouldn't edit the vulnerability out - that's just confusing and pointless.)

The trouble is, your rule also explicitly and strongly recommends against plainly useful edits in the following situations:

  • The OP has posted Python code, asking "Why do I get a ValueError on line 7 here?", and the indentation of the Python is broken such that trying to run the code just throws an IndendationError, line 7 is never reached, and it's obvious that the indentation has been broken in the process of copying and pasting the code because the broken indentation is the only thing preventing the code from exhibiting the behavior described by the asker. (This isn't a hypothetical situation, it's fairly common in the Python tag. Since joining SO I've probably seen 10+ questions by new users who broke their indentation when copying and pasting the code, but I've never seen a question where indentation errors were a relevant part of the question.)
  • More generally, someone posts code saying "This code exhibits unexpected behavior X - why?", but there's a trivial error earlier in the code that crashes the code before you even reach the part that would cause the unexpected behavior. It's easily fixable, and it looks like the mistake was probably introduced by the author either when anonymizing their original code or creating a minimal demo case without testing it as thoroughly as they should've.

In both the above cases, I think that you should edit the code in the question to fix the incidental bugs that are preventing the code from exhibiting the problem that the author is actually asking about. Doing so makes the question more useful and not only preserves but clarifies the author's original intent. Discouraging such edits seems like a bad idea.

The spirit of the guidance, I feel, ought to be

Correcting what you think are typos or irrelevant mistakes might well change the entire question or confuse the author...

... so bear that in mind be very careful not to do either of those things!

Instead, you've effectively said

Correcting what you think are typos or irrelevant mistakes might well change the entire question or confuse the author...

... so just don't do it! Trust us, you're not clever enough to figure out the difference between a helpful edit that clarifies the author's intent and one that changes the entire question.

  • Then add a minor "when they might be the cause of the problem" to the Python section. I don't really care about the wording.
    – Bart
    Commented Jul 27, 2013 at 8:41
  • 2
    "It's easily fixable, and it looks like the mistake was probably introduced by the author either when anonymizing their original code or creating a minimal demo case without testing it as thoroughly as they should've." ... then they should go back and show us their actual code, or produce an actual sample which exhibits the problems stated.
    – Bart
    Commented Jul 27, 2013 at 8:43
  • @Bart Sure, they should. Heck, they should have posted code that properly exhibited the problem originally. But they didn't, and now the issue exists, and it's probably easier to just edit it than to point out the problem to the author and ask them to fix it. Almost all edits are about fixing things the author has done wrong; I don't understand why you object to editing in the particular case described.
    – Mark Amery
    Commented Jul 27, 2013 at 8:46
  • 3
    Because your edits will not necessarily reflect the situation at hand for the OP. There are tons of C++ examples where the OP says "This is what happens" and the comments are "No, because that won't even compile". I can correct those to something that will exhibit a similar problem, but there is no guarantee it reflects the OP's exact situation. Especially given the often vague descriptions. Have them correct it and show it to us. Then we're on the same page. Are there scenarios where it's an obvious typo? Sure. But there are plenty where this is not the case.
    – Bart
    Commented Jul 27, 2013 at 8:50
  • @Bart If the code can't obviously be fixed by a trivial correction that makes it exhibit the problem being asked about, then you we're agreed that you shouldn't edit. (You should probably downvote, and comment if nobody else has already.) What I don't understand is why you feel the need to generalize from that that any and all behavior-changing code edits are harmful, when it seems to me that there are cases (like those I described) where they are obviously helpful and the concerns you've raised don't apply.
    – Mark Amery
    Commented Jul 27, 2013 at 8:55
  • There are always cases which will fall outside of the general rules. And heck, I've made edits that would be advised against. (One character edit anyone?). The problem in giving leeway is that I fear users will only see what they are allowed to do. Some of the general interpretations that come up here regarding tool recommendations for example are a direct outflow of a fairly innocuous statement on programming tools in the Help Center. Code edits are tricky. Reviews are not always great. I'd rather say "no" and have them understand "but" as they mature on the site than say "yes, carefully".
    – Bart
    Commented Jul 27, 2013 at 9:01

You must log in to answer this question.

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