# Preventing the ability to re-open off-topic questions by explaining how it's broken in an answer

Earlier this year I posted an answer to a question, saying that it's broken in a way that OP don't think, explaining it a bit, and then wrote a comment saying it's off-topic, and voted to close. Others voted to close too, and the question was closed. But the way that I handled that question irked me afterwards, in a way that I still vividly remember. I dismissed this, as it was just a one off thing.

Today another high ranking member done roughly the same. (They didn't comment or say what the answer was until I asked what the answer was, however.)

When I done this before, I decided to not do it again, as it blocks the question from being fixed and re-opened. The first question probably needed a substantial re-write, but the second however just needs to add if not nums: return False. And that answer prevents the asker from just adding one or two lines to fix the question and make it on-topic, and OP now needs to ask a new question. (As fixing the question will invalidate the 'answer')

If we do:
Should they follow a certain format? I.e need a comment, description or anything else.

If we do not:
How do should we handle such 'answers'?

• – Vogel612 Aug 15 '16 at 14:24
• – janos Aug 15 '16 at 15:26

The first consideration is, is the code broken in a way that makes it off-topic? It's only off-topic if the question asks for help to fix a bug (or if it looks like the author is unfairly feigning ignorance by not even bothering to test for obvious bugs). Corner case failures do not make the question off-topic, and should be addressed in answers.

It does not make sense for the same person vote to close a question and to post a review.

• If you feel that the code is blatantly broken, vote to close it. You are encouraged, but not required, to leave an explanatory comment. Please do not post a review.

If the explanatory comment is too long, post it as a Community Wiki answer instead. You won't earn any reputation from it. The content does not need to meet our usual requirement for insight. We can just treat such posts as comments, and dispose of them when the question is eventually revised.

• If you believe that the author is genuinely unaware that the code is broken, then just answer it normally.

• Huh, a CW/disposable answer could actually be the best solution here. – Mathieu Guindon Aug 15 '16 at 17:44

Hypothetical situation:

1. OP asks a question involving broken code.
2. Question starts collecting comments asking to clarify or explaining what's wrong with the question; down and close votes rain, too.
3. Someone posts an answer that fixes OP's bug.

And then the question collects its 5th close vote, and sits there collecting dust in a broken state, and OP can't salvage their post without invalidating the answer.

Regulars and high-rank users don't face this problem, but first-timers and the hypothetical OP here in the above situation do:

## Every closed, deleted, downvoted question you ask takes you closer to an automatic question ban.

And the only way to recover from bad standing, is to edit and improve your existing posts.

If some high-ranking user got in and answered every single one of your off-topic questions, you're stuck.

# So no, we don't want these answers. Ideally, they should be removed.

If OP wants a peer review and edits their question with the working code, IMO it's the hasty FGITW non-review answer that should be removed; OP is entitled to have a chance to fix their post and their standing, without having to create a new question (heck, what if they're Q-banned by then?) - it's a matter of fairness.

Here's a quick history of what happened on this question. The OP wrote:

but for some reasons I don't know, although my heap sort program works well, I still got the runtime rejection from Leetcode.

To interpret this, you need to know that code challenge sites like Leetcode typically categorize submissions as follows:

• "passed" — program gave the right output to all test cases.
• "wrong output" — program gave wrong output to a test case.
• "time limit exceeded" — program took too long to complete a test case.
• "runtime error" — program crashed or raised an exception on a test case.

So the OP's phrasing indicates that the code was categorized as "runtime error" by Leetcode. Hence the OP knows that there is a bug is the program, but can't find it. This is off topic for Code Review ("Questions seeking help about debugging code are off-topic"), so I voted to close.

Nonetheless, I thought the bug might be easy to spot, so I ran some test cases and quickly found it. Leetcode doesn't give you the traceback or any other information from a runtime error (to avoid revealing its test cases), so I could help the OP by giving them the traceback from the exception. I didn't want to paste the traceback into a comment as it loses formatting, so I posted it as an answer and referred to the answer from the comment.

Sorry for any trouble caused — my only goal in posting the answer was to provide helpful information to OP. 200_success's suggestion to make the answer community wiki looks good to me.