How broken does code have to be to for a question to be closed?

Question

I recently voted to close this question:

The longest subsequence with specified difference between min and max

Originally I thought the code was really bad because the OP claimed a linear solution, so I didn't see the array sort at the top. But even with a sorted array, the code still had what I considered major bugs in it.

If I find a bug with the first test input that I try, in my mind the OP didn't spend enough time testing the code. But does that make the code "broken" enough to close the question, or do we simply allow the question and point out all the bugs?

Answer 1

OP doesn't seem to know their code is broken. Perhaps due to insufficient testing, but to the best of their knowledge, the code works and produces the expected output.

The "spirit" of the "working code" rule isn't to forbid code with bugs - in fact part of the peer review exercise is to highlight unforeseen edge cases and other issues - it's very possible that a programmer might have written code that works for the input they're feeding it, but that breaks in other situations; if OP isn't aware of this, they won't be asking for solutions to such specific issues.

The "spirit" of the "working code" rule is that on-topic CR questions aren't questions asking things like "my code does X, but it should do Y - how do I fix that?", which would typically be on-topic on Stack Overflow.

A java gold-badger moderator reviewed the code in the close queue, and found no convincing evidence of how badly the code might be broken, and chose to leave it open.

I think the best thing to do is to show everyone what you're seeing that everybody else missed, and then collect the upvotes!

Answer 2

The rule states that the code must work correctly, to the best of the author's knowledge. Usually, if the author does not mention any known bugs, then it's an allowable question. That said, if the code is very obviously broken (won't run at all, or fails on a simple test case), I will generally close it anyway, because

• It would be unfair to skirt the rule by being oblivious to glaring errors.
• Telling the author that the code is broken is a valuable form of feedback in itself.
• Glaring errors would be an obstacle to getting more meaningful reviews. Putting a question on hold, especially before answers start rolling in, gives the author a chance to fix the code so that answers can focus on more interesting issues.