One of our current close reasons reads as follows:
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
(For context, SSCCE stands for Short, Self-Contained, Correct (Compilable) Example.)
This close reason seems to be intended as a catch-all close reason for badly-formulated debugging questions. Unfortunately, there are a couple of things I think are wrong with it.
The first is that the close reason links to SSCCE, but the wording of close reason doesn't cover the 'short' aspect of SSCCE at all and arguably doesn't cover the 'self-contained' aspect either. "Wall of code" questions and questions that include only some of the code needed to replicate a problem are both a plague on SO, and it's kind of unclear whether this close reason covers them or not.
The second, and more important problem is that the close reasons fail to make clear what specifically is wrong with the question being closed, or how to remedy it. There are really lots of possible problems being rolled into a single close reason, here.
In describing the components that make for a good debugging question, SSCCE implicitly provides us with a list of ways that questions about debugging specific problems can go wrong:
- SHORT: By providing a needlessly long example, full of fluff that distracts from the actual problem.
- SELF-CONTAINED: By providing an example that isn't self-contained, and so can't be used by answerers to reproduce the problem without divining the crucial details that have been left out.
- CORRECT: By providing an example that doesn't actually exhibit the behaviour being asked about, or doesn't compile or run at all (where that isn't the problem being described, of course).
- EXAMPLE: By failing to provide an example at all.
There's also another potential failure mode that the close reason describes:
- DESCRIBE THE SPECIFIC PROBLEM: The question provides some code, but doesn't say what error it throws or what aspect of its behavior is unexpected or undesirable.
Why not use these five failure modes as close reasons? It seems to me that our current close reason is, ironically, failing to describe the specific problem. Breaking that single close reason down into one reason for each of the sub-cases it covers would allow us to give much more detailed feedback about what's wrong with a question, both to the question asker (so that they can more easily fix the problem) and to other users (so that they can more easily learn and understand our standards). I'm imagining the wording of these new close reasons being something like this:
Please provide example code that illustrates the problem you are experiencing. See SSCCE.org for guidance.
Your example includes much more code than is necessary. Try to remove details that aren't relevant and present the smallest possible test case that illustrates the problem. See SSCCE.org for guidance.
Your example includes some of the code related to your problem, but some important pieces of code necessary to reproduce your problem are missing. Please include all the code needed to reproduce the problem.
The example code included in the question does not exhibit the problem the question asks about. Examples should demonstrate the problem, and code examples intended to demonstrate an error or problem that occurs at run-time should not contain errors that prevent them from compiling or running.
Failure to describe the problem:
You have provided example code, but it is not clear what specific problem you are having. Please state what error you observe when running the code, or describe the difference between the code's actual behavior and the behavior that you expected or intended.
These five close reasons could appear when you select the existing "describe the specific problem" / SSCCE.org close reason, and be displayed below the existing message, or they could simply all be listed under the "Off Topic" section instead of the current close reason that spans all five of them.