2 added 209 characters in body
source | link
  • you see an error in their code that is causing the thing they are asking about. You just found the answer to their question. If you see an answer that already says that, vote it up. Otherwise, answer the question.
  • you see an another error that hasn't hurt them yet, but that will when they fix their main problem. (Eg the question they are asking is "Why won't this compile?" and someone has already told them that they have a problem on line 10, but you can see something on line 11 that will cause an error at runtime.) Add a comment on the question. Alternatively, if you are writing your own answer anyway (because no-one has answered the question as asked), toss in a "ps" or "btw" about the other problem. Do not add an answer of your own only to make this distinction.
  • you see an error in their code that is not obvious (some might even say a matter of style, preference or practices) and is not what they asked about. (Eg sql injection vulnerability, keeping passwords in plain text rather than hashed, buffer overrun vulnerability, functions too long, too much code duplication, not internationalizable, using a library you think is inferior etc). As before, a comment on the question or a paragraph in your own answer, but include a link to another question, a blog, or a reliable web page explaining it. Don't try to fit the whole issue into a small space and don't encourage discussion of that issue in place. And don't add an answer that differs from another only by including this information.

For an answer, there are threefour possibilities:

  • the error is obvious (forgotten semi colon, missing cast, nit where it should be int - add a comment, and after a few days, edit if you have the power. Don't use suggested edits for this unless the answerer commented saying "you're right, thanks" but doesn't edit it. Someone with edit powers may do the edit, or worst case, future readers will have your comment to help them if they run into trouble using the answer.
  • the error is factual (that API takes 4 parameters, not 3) and non controversial, but not an obvious typo. Comment. After a few hours with no reply, add your own answer that does it correctly.
  • the "error" is a difference of style or practice as in the third possibility for a question. Comment, but do not add an answer that does not answer the question. If the question is "how do I make this a parameterized query to avoid SQL injection?" and an answer has been provided that does that, don't write a different answer that does that but hashes the passwords. Instead, give them a comment with a link so they can learn why they should hash the passwords, and perhaps a link to a question and answer that show them how. Otherwise you're hijacking their question.
  • the "error" is that the author didn't comment on flaws in the code provided in the question. You have commented on the question already pointing out these flaws, so leave the answers alone. They are under no obligation to fix all the flaws in the question. They're explaining the null reference exception or the file-not-found error or the compiler warning. Don't edit, comment, or downvote them for not mentioning memory leaks, sql injection or whatnot that was already in the question.
  • you see an error in their code that is causing the thing they are asking about. You just found the answer to their question. If you see an answer that already says that, vote it up. Otherwise, answer the question.
  • you see an another error that hasn't hurt them yet, but that will when they fix their main problem. (Eg the question they are asking is "Why won't this compile?" and someone has already told them that they have a problem on line 10, but you can see something on line 11 that will cause an error at runtime.) Add a comment on the question. Alternatively, if you are writing your own answer, toss in a "ps" or "btw" about the other problem
  • you see an error in their code that is not obvious (some might even say a matter of style, preference or practices) and is not what they asked about. (Eg sql injection vulnerability, keeping passwords in plain text rather than hashed, buffer overrun vulnerability, functions too long, too much code duplication, not internationalizable, using a library you think is inferior etc). As before, a comment on the question or a paragraph in your own answer, but include a link to another question, a blog, or a reliable web page explaining it. Don't try to fit the whole issue into a small space and don't encourage discussion of that issue in place.

For an answer, there are three possibilities:

  • the error is obvious (forgotten semi colon, missing cast, nit where it should be int - add a comment, and after a few days, edit if you have the power. Don't use suggested edits for this unless the answerer commented saying "you're right, thanks" but doesn't edit it. Someone with edit powers may do the edit, or worst case, future readers will have your comment to help them if they run into trouble using the answer.
  • the error is factual (that API takes 4 parameters, not 3) and non controversial, but not an obvious typo. Comment. After a few hours with no reply, add your own answer that does it correctly.
  • the "error" is a difference of style or practice as in the third possibility for a question. Comment, but do not add an answer that does not answer the question. If the question is "how do I make this a parameterized query to avoid SQL injection?" and an answer has been provided that does that, don't write a different answer that does that but hashes the passwords. Instead, give them a comment with a link so they can learn why they should hash the passwords, and perhaps a link to a question and answer that show them how. Otherwise you're hijacking their question.
  • you see an error in their code that is causing the thing they are asking about. You just found the answer to their question. If you see an answer that already says that, vote it up. Otherwise, answer the question.
  • you see an another error that hasn't hurt them yet, but that will when they fix their main problem. (Eg the question they are asking is "Why won't this compile?" and someone has already told them that they have a problem on line 10, but you can see something on line 11 that will cause an error at runtime.) Add a comment on the question. Alternatively, if you are writing your own answer anyway (because no-one has answered the question as asked), toss in a "ps" or "btw" about the other problem. Do not add an answer of your own only to make this distinction.
  • you see an error in their code that is not obvious (some might even say a matter of style, preference or practices) and is not what they asked about. (Eg sql injection vulnerability, keeping passwords in plain text rather than hashed, buffer overrun vulnerability, functions too long, too much code duplication, not internationalizable, using a library you think is inferior etc). As before, a comment on the question or a paragraph in your own answer, but include a link to another question, a blog, or a reliable web page explaining it. Don't try to fit the whole issue into a small space and don't encourage discussion of that issue in place. And don't add an answer that differs from another only by including this information.

For an answer, there are four possibilities:

  • the error is obvious (forgotten semi colon, missing cast, nit where it should be int - add a comment, and after a few days, edit if you have the power. Don't use suggested edits for this unless the answerer commented saying "you're right, thanks" but doesn't edit it. Someone with edit powers may do the edit, or worst case, future readers will have your comment to help them if they run into trouble using the answer.
  • the error is factual (that API takes 4 parameters, not 3) and non controversial, but not an obvious typo. Comment. After a few hours with no reply, add your own answer that does it correctly.
  • the "error" is a difference of style or practice as in the third possibility for a question. Comment, but do not add an answer that does not answer the question. If the question is "how do I make this a parameterized query to avoid SQL injection?" and an answer has been provided that does that, don't write a different answer that does that but hashes the passwords. Instead, give them a comment with a link so they can learn why they should hash the passwords, and perhaps a link to a question and answer that show them how. Otherwise you're hijacking their question.
  • the "error" is that the author didn't comment on flaws in the code provided in the question. You have commented on the question already pointing out these flaws, so leave the answers alone. They are under no obligation to fix all the flaws in the question. They're explaining the null reference exception or the file-not-found error or the compiler warning. Don't edit, comment, or downvote them for not mentioning memory leaks, sql injection or whatnot that was already in the question.
1
source | link

The response is different whether you want to fix code in a question or an answer. They are entirely different.

For a question, there are three possibilities:

  • you see an error in their code that is causing the thing they are asking about. You just found the answer to their question. If you see an answer that already says that, vote it up. Otherwise, answer the question.
  • you see an another error that hasn't hurt them yet, but that will when they fix their main problem. (Eg the question they are asking is "Why won't this compile?" and someone has already told them that they have a problem on line 10, but you can see something on line 11 that will cause an error at runtime.) Add a comment on the question. Alternatively, if you are writing your own answer, toss in a "ps" or "btw" about the other problem
  • you see an error in their code that is not obvious (some might even say a matter of style, preference or practices) and is not what they asked about. (Eg sql injection vulnerability, keeping passwords in plain text rather than hashed, buffer overrun vulnerability, functions too long, too much code duplication, not internationalizable, using a library you think is inferior etc). As before, a comment on the question or a paragraph in your own answer, but include a link to another question, a blog, or a reliable web page explaining it. Don't try to fit the whole issue into a small space and don't encourage discussion of that issue in place.

For an answer, there are three possibilities:

  • the error is obvious (forgotten semi colon, missing cast, nit where it should be int - add a comment, and after a few days, edit if you have the power. Don't use suggested edits for this unless the answerer commented saying "you're right, thanks" but doesn't edit it. Someone with edit powers may do the edit, or worst case, future readers will have your comment to help them if they run into trouble using the answer.
  • the error is factual (that API takes 4 parameters, not 3) and non controversial, but not an obvious typo. Comment. After a few hours with no reply, add your own answer that does it correctly.
  • the "error" is a difference of style or practice as in the third possibility for a question. Comment, but do not add an answer that does not answer the question. If the question is "how do I make this a parameterized query to avoid SQL injection?" and an answer has been provided that does that, don't write a different answer that does that but hashes the passwords. Instead, give them a comment with a link so they can learn why they should hash the passwords, and perhaps a link to a question and answer that show them how. Otherwise you're hijacking their question.

My reasoning here is this: SO is a place to get answers to questions, not a place to make your code perfect in a discussion format. Answers should rarely say "you're doing it wrong" - they should answer the question. Comments can say "you're doing it wrong" and good ones provide links to help the person learn.