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:

No example:

Please provide example code that illustrates the problem you are experiencing. See SSCCE.org for guidance.

Long example:

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.

Non-self-contained example:

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.

Non-correct example:

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.

  • 8
    Why not use the existing reason and leave a comment if you want to give more detail? Which of the new reasons would I choose if the code example was both long/incorrect? – Geobits Dec 12 '13 at 21:20

Why not use these five failure modes as close reasons?

  1. The "questions concerning problems with your code" close reason isn't about the five failure modes that you described. It is about blocking dump-code, how-fix questions. SSCCE.ORG is just guidance, not a mandate; we don't necessarily close questions just because they fail to meet every guideline there.

  2. Adding a close reason is an extremely expensive operation, from a user community perspective. The list of close reasons must be kept very small or it becomes unworkable.

The current crop of close reasons was heavily discussed and vetted before they were rolled out. The resulting reasons are meant to target specific, very common categories of problem questions, and it is not intended to be comprehensive, by design.

In other words, your suggestions, while they have merit, don't provide sufficient value to overcome the expense of adding another close reason, let alone three.

  • 4
    I will close questions if someone's block of code is not 'short'. Normally this happens when they decide to post a whole file worth of code instead of just the part needed to reproduce this issue. I try not to do it unless it's egregious; but it is a criteria. No one should have to go through a whole page of code to look at a 3 line issue. – George Stocker Dec 12 '13 at 21:43
  • It is a criteria, it's just not worthy of its own separate close reason. – user102937 Dec 12 '13 at 21:44
  • 3
    Agreed on both points. I was just bringing to light that I will vote to close a question where one of the parts of the SSCCE is severely lacking. It seemed like from your answer that you were ok with long code samples ( or that the criteria individually do not warrant closing a question). To my mind, each is necessary, but they are bendable. – George Stocker Dec 12 '13 at 22:06
  • Sometimes it requires a lot of code to show an example though. Closing a question based purely on LoC would lead to some good questions being closed. On average though, code wall leads to facepalm. – Travis J Dec 12 '13 at 23:23
  • @GeorgeStocker About the 'short' part... – Bernhard Barker Dec 13 '13 at 3:38
  • @TravisJ Sure - the 'short' in SSCCE needs to be interpreted as "not needlessly excessively long" for it to be sensible. What that means in context depends upon the specific problem you're asking about. – Mark Amery Dec 13 '13 at 9:50

We really shouldn't be further complicating the close-vote reason tree. In fact, the close votes queue hasn't seemed to quite recover from the last time we changed close vote reasons.

If you have a more specific message to leave the OP, than you can leave a comments. We don't need a separate close reason for every possible comment that you can leave regarding why you're closing a post.

  • 3
    The close votes queue isn't clogged because people don't understand the close reasons. – user102937 Dec 12 '13 at 21:26
  • @TheGrinch I don't know about that. It seemed that the rate at which the close votes queue grew increased a lot after we made the change. Where before we would get an extra backlog of 100 or 200 per week, now we're getting more than a thousand per week. – Sam I am says Reinstate Monica Dec 12 '13 at 21:29
  • The "you can leave a comment instead" argument seems to apply equally to having specific close reasons at all. The benefit - as I see it - of having specific close reasons is that they let you rapidly communicate detail about what is wrong with a question without having to type out a comment each time you vote to close something. That benefit is reduced if the close reasons are more vague than is necessary. – Mark Amery Dec 12 '13 at 21:30
  • 1
    @MarkAmery: There is a balance between canned and custom close reasons. Canned close reasons serve to categorize the vast majority of legitimate closures, and reduce the friction required to close. Custom close reasons serve as a safety valve to close questions that don't fit neatly into one of the existing canned categories. We're doing well if we can capture 90 percent of the closures using canned close reasons (which I believe we already achieve now), and use custom close reasons for the remaining 10 percent. – user102937 Dec 12 '13 at 21:46
  • @MarkAmery the close reasons prevent questions from getting closed with no explanation at all. – Sam I am says Reinstate Monica Dec 12 '13 at 21:47
  • @TheGrinch Sam's (first) comment seems like something worth investigating, if it hasn't already been. – Bernhard Barker Dec 13 '13 at 3:39

You must log in to answer this question.

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