Return to Answer

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.

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.

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.

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.

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.

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.