4
\$\begingroup\$

Assume a person is asking about their broken code and someone suffering from FGITW-syndrome immediately answers it. Then maybe the answer and/or even the question gets upvoted.
This completely undermines the purpose of this site and basically turns it into a slower/smaller version of SO.

I see two ways to address this problem:

As the problem persists I was wondering if there is anything else that can be done to prevent this?

\$\endgroup\$
2
  • 3
    \$\begingroup\$ It may not be FGITW. It is easy enough to forget that you're looking at a CR question and not a SO one. I've nearly done that myself a few times, realized what site I was on, then flagged to close or migrate. \$\endgroup\$
    – 1201ProgramAlarm
    Commented Aug 20, 2018 at 0:40
  • \$\begingroup\$ I am downvoting this because I sincerely don't think this is a big problem that needs to be addressed. No matter what we do there will always be people who will answer off-topic questions. \$\endgroup\$
    – Simon Forsberg Mod
    Commented Sep 1, 2018 at 12:11

2 Answers 2

Reset to default
6
\$\begingroup\$

Personally, when I see that happen, I down-vote the answer (and the question). Well, let me clarify, if the answer is about fixing the problem I downvote it. If the answer appears to be a legitimate review, I won't. I also vote to close the question.

On occasion I have commented for people to not answer off-topic questions too.

Together, those actions go to educating answerers.

Your suggestion to prevent people asking off-topic questions is a long-standing issue we have had on Code Review. A number of meta questions have been discussed regarding doing that. It is an ongoing effort, and any suggestions you have for preventing, or reducing off-topic questions would be welcome.

\$\endgroup\$
1
  • 3
    \$\begingroup\$ Closing questions as early as possible helps prevent people from answering them. Downvoting the question is a pretty useful hint to other users that it may need to be closed. \$\endgroup\$
    – 200_success
    Commented Aug 24, 2018 at 5:53
5
\$\begingroup\$

I basically follow this reasoning when dealing with "broken code":

First of all, you must never fix a bug in the question just by editing the question. This is Code Review, not GitHub hack fest. (The only possible exception would be obvious trivial whitespace issues due to the author's inability to copy-paste the code correctly into the text box.)

  • If the question specifically asks for help to get the code to compile, fix a bug, or add a feature, then it's off-topic. Please don't answer it, as it limits our ability to regularize the question.

    Ideally, we would close it, let the author fix the problem, then reopen it for a code review. Once an answer that reviews the broken code has been posted, though, we can't do that anymore. The question stays in limbo forever, which is not good for anyone.

  • Otherwise, if the code is broken, then it requires a judgement call.

    Is it obviously broken, as in "you obviously didn't test this code at all"? If so, it should be considered off-topic. Close/flag it, leave a comment, and don't answer.

    If it's plausible that the author was unaware of the brokenness, then it's a fine question. One of the purposes of Code Review is to point out problems that the programmer didn't know about.

Expanding on "unaware of brokenness",

It's rarely possible to test code to 100% and be 100% confident that it works. It's often bound to be an edge-case somewhere. That is why we allow the "unaware of the brokenness" case. Reviewing code that has a little edge-case that doesn't work is often more helpful than closing the code for being broken. If you want to have a long discussion about this then you should consider taking it to chat, or you might want to lookup previous meta questions about the subject, or start a new meta question.

\$\endgroup\$

You must log in to answer this question.

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