I don't think there is a detailed site policy and I don't want there to be one, because it would be too complex to codify*. No policy, however sensitively and scrupulously defined and flexibly applied, can replace learning through experience. I much prefer the SE way of respecting experienced users and having an initial learning process (suggesting edits which are checked by the community) and checks and balances in place.
Anyway, FWIW, here is my take (I guess I am a pretty prolific editor) in more detail, subjective as it must remain.
There is a rather generic list of guidelines that pops up at the side of the screen when, as an unprivileged user, you set out to suggest an edit. I can't remember what that looks like on Ask Ubuntu but I'm going to assume it's similar to what I see on U&L and Stack Overflow:
How to Edit
► fix grammatical or spelling errors
► clarify meaning without changing it
► correct minor mistakes
► add related resources or links
► always respect the original author
There's no special mention of code here, so we can assume that the same guidelines apply to code: I should correct minor mistakes. There is no mention of formatting, which is probably in need of editing more often than anything else, but I assume you mean the actual code text, not the formatting.
I believe that "minor mistakes" is deliberately vague: as editors we are trusted to know when the mistake can be salvaged by editing, and when we should do something else instead. I don't mean that we are or should be expected to always know that, I mean, that if you set out to edit a post, you should have the knowledge gained from observation and experience to do so appropriately. (As mentioned by @edwinksl, In the context of review - if you are unsure, the skip button is your friend)
I err on the side of editing. My bottom line is, if I can improve the site by editing, I should do so. Edits can always be rolled back or re-edits done. In practice "improving the site by editing" is a complex goal and there are multiple factors to consider (*this is why I think no policy could be codified) - in particular I always first ask myself:
- Is the post author experienced and active on the site?
- If so, I will usually comment rather than editing unless there is some obvious typo or slip-up
- If not, I will usually go ahead and edit, with a couple of exceptions*
If I go ahead and edit, here's what I do in situations where code is involved, not including formatting:
- If the poster has not included commands that I think should have been included, I include them (as a fairly extreme example, if a post says "pass
intel_idle.max_cstate=1 as a boot parameter" I will generally edit into it an explanation of how to set boot parameters with commands. Less drastically, if a post mentions installing a package, I will often edit in the command to install the package).
- If there is something in the code that I am fairly sure is an error, I will correct it.
- I usually switch out any backticks used for command substitution and replace with
$() because of the potential of the former to cause markdown-mixups
- If someone has written something similar to what I would write as an answer myself, and I can think of an additional related command suggestion, I will usually edit it into the answer rather than writing an answer of my own.
- If the code makes what I consider a bad minor decision (typically
sudo gedit (or
sudo <any graphical application>) I will "fix" it (
sudo -H gedit and so on)
*situations when I don't usually edit:
- If the code makes what I consider a bad major (ie the answer will need to take a significantly different approach to avoid it) decision or fails in a way I can't fix (when I test it), I will usually leave a comment (and downvote if warranted) instead of editing.
- If I think the code could be simplified or improved, I will usually comment instead of editing.
I should say that I always eventually check back on my comments. If a post still seems bad after I've given time for it to be fixed by the poster after leaving a comment, I will either (preferably) edit it or, if not done already, downvote it. Occasionally, I leave a comment for the sake of future visitors in cases where I have no intention of editing the post, but in general I will edit unless there is a compelling reason not to (generally that the post is an established one and the author is active).
Context sometimes matters - what else is going on besides the code in this post? Is it one of numerous answers to a question? Is that question ambiguously phrased, with answers addressing different possible sides of it? Respecting the original poster might be quite a wide ranging consideration - I try to look around to see if I am treading on any other toes too when editing (for example, if I "clarify" a question, am I making one of the answers lose meaning and usefulness? How can I avoid that?)