I have noticed recently that when I reformat code in a question or answer (generally from something with no carriage-returns or something extremely hard to read to properly indented code for readability purposes), my edits usually get rejected.

Is there a specific policy against these kinds of edits?

Is clearly readable code formatting not important on stackoverflow?

  • 12
    Your edits often seem to change much more: this and this. I'm surprised you haven't been given a break from editing.
    – devnull
    Apr 7, 2014 at 3:31
  • 1
    You've certainly got lucky with some of your edits that have been approved.
    – devnull
    Apr 7, 2014 at 3:32
  • Two attempts to clarify an incomplete code example. Not exactly what I would term 'often'.
    – Jason
    Apr 7, 2014 at 3:32
  • @devnull - lucky? How so?
    – Jason
    Apr 7, 2014 at 3:33
  • 5
    Attempts to clarify an incomplete code example? Post your own answers if you think that other answers lack rather than making radical changes.
    – devnull
    Apr 7, 2014 at 3:35
  • I wouldn't say I edit to make 'radical' changes, but I get your point.
    – Jason
    Apr 7, 2014 at 3:36
  • 2
    If you are formatting code, consider improving the question too. Suggested edits for formatting the code in a badly phrased question that do not improve the question otherwise are liable to be rejected.
    – devnull
    Apr 7, 2014 at 3:37
  • 2
    "Why do code formatting edits always get rejected?" - "Always" is not really true here. As devnull said, too minor code formatting edits will get rejected, but good code formatting edits (that may address other issues in a post) will get approved, as long as they are not a radical change.
    – Blue Ice
    Apr 7, 2014 at 3:43
  • 5
    +1 for asking here and making efforts to improve. Well done! Apr 7, 2014 at 6:38

2 Answers 2


If you're wondering why this edit was rejected, it's just because another user with full editing privileges edited at the same time as you.

However, most of your other edits do a lot more than formatting. They change the code (fixing errors in the code, adding more code, etc.), which shouldn't be done in an edit. Instead, comment and say:

Hey, you need an extra return null.

Or something similar.

Also, please improve everything that can be improved in a post when editing. If you're editing to fix the code formatting, fix the grammar, formatting, and other such stuff too! If there's nothing else to improve, that's okay too, as minor edits are encouraged, but make sure to check.

  • Ok, that makes more sense.
    – Jason
    Apr 7, 2014 at 3:35
  • 1
    Your answer is very misleading. Fixing minor errors in answers is encouraged. Apr 7, 2014 at 13:21
  • @Gilles, I can't see how this answer suggests otherwise... I guess you mean the "changing code (fixing errors", but he never says minor, and OPs code changes lean further towards the side of radical.
    – OGHaza
    Apr 7, 2014 at 14:00
  • @Gilles Yeah... didn't mean it to sound that way. I was a little sleepy when posting this. :P Is it better now? Feel free to edit if you think you can make it clearer.
    – hichris123
    Apr 7, 2014 at 14:45
  • @OGHaza I haven't gone through Jason's suggested edits. As a generic statement, this answer is wrong. “Fixing errors in the code […] shouldn't be done in an edit” is wrong; it directly contradicts the rules about editing (“When should I edit posts? […] To correct minor mistakes”). Apr 7, 2014 at 14:58
  • 1
    @Gilles "Minor mistakes" are e.g. correcting array[x) = 3 to array[x] = 3, when the OP clearly intended to be correct but made a typo.
    – Jason C
    Apr 7, 2014 at 15:00

If you spot answers that you'd like to make significant changes to the code in, instead of sliding an edit in, point out the issue in a comment.

If you point it out in a comment:

  1. You give the OP an opportunity to clarify whether you are justified or not (perhaps you were mistaken, it happens). By suggesting that in a comment, you'd give the OP the opportunity to point this out.

  2. You draw visible attention to the issue instead of relying on people always checking the revision histories. It is much less likely for somebody who has already read the answer to notice a change in an edit vs. a discussion in comments.

  3. You give the OP an opportunity to potentially make a better improvement, based on your suggestion, that is more aligned with his answer - and the OP may choose to improve other parts of the answer as well (e.g. adding an explanation of the rationale for the change beyond simply making the change, etc.)

  4. Explaining the rationale gives the OP the opportunity to learn.

  5. Even if the OP doesn't make the change, the discussion is now in comments for everybody to see; and if your comment was helpful, comment upvotes tend to make those types of comments more visible. People do frequently read the comments as well as the answers when looking for an answer.

By making code change edits silently, it's a bit of a disservice to the OP, other readers, and the answer itself, as it doesn't draw attention to the potential issue and doesn't open any possibilities for discussion.

As a specific example, consider your edit here. Major vs. minor change aside, this wasn't actually valid:

  • The original question cited a function that returned an int, and null is not a valid int in Java.

  • The answer wasn't attempting to address what should happen in the case that nothing was found (we have no way of knowing what "magic" value could indicate "not found" in the original snippet - heck, maybe the asker actually wants to throw an exception instead of returning - and the answerer correctly made no assumptions).

By suggesting this as a comment, the answerer could have explained it / clarified it. By suggesting it in an edit, it can only be rejected without opportunity for explanation. This specific case is a prime example of when a comment would have been more beneficial to all involved (you, the answerer, the asker, and all readers).

You must log in to answer this question.

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