Should the "broken code" close reason be reworded?

Question

Here are our current close reasons:

As @rolfl explains here, the gist of each of these three close reasons can be roughly summarized as the opposites of:

1. your code works as intended
2. it is your code (real code)
3. the question must have the right presentation (include the actual code).

Importantly, the linked-to answer explains that a question seeking an explanation of code (presuming it is written by the OP and not qualifying under the "other people's code" close reason) should be closed using the first close reason. Effectively, if the code requires explanation, it's not really working as intended is it?

Currently, the close reason reads as such:

Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it.

There are a few confusing points here.

code not written - how come this doesn't fall under the pseudo/hypothetical/stub code reason or the "include code to be reviewed" reason?

This close reason also currently seems to place an emphasis on "broken" code. Yes, if you follow the link through, we'll see that "broken" includes code that compiles and runs without exception but produces unwanted results, and we see comments such as "my code isn't broken, it just doesn't give the right result".

If questions seeking explanations fall under this umbrella (or any question which simply isn't actually seeking a review), why is there nothing in the close reason to indicate this? It's confusing to close voters and posters of closed questions alike.

And finally, is this part necessary at all:

After the question has been edited to contain working code, we will consider reopening it.

Does this mean that as long as the code works as intended, the question will be reopened? Does this mean that the other close reasons (which don't include this comment) won't be considered for reopening?

Answer 1

code not written - how come this doesn't fall under the pseudo/hypothetical/stub code reason or the "include code to be reviewed" reason?

I certainly wasn't around when these are put up (:p), so I'll have to infer. Could it be merely a simple defense mechanism against one-liner questions like the following?

I need help to solve Project Euler #1. Thanks!

To flip the question around, one can also ask:

Why are broken code and unwritten code lumped together?

I'll further infer that it's because for the purpose of reviewing code, code that does not do what it's meant to do is no better than code that's not written yet.

After the question has been edited to contain working code, we will consider reopening it.

Ok, this I agree is not specific to just the first close reason. Probably we'll need to duplicate it for the other reasons as well. Or maybe omit it entirely with the expectation that any improved questions are always considered for re-opening (and why wouldn't that be?).

edit

Pseudocode, hypothetical code, or stub code should be replaced by a concrete example.

I think the linked Meta answer whenever we select this explains all three pretty well. All three are appended with the extra clause "... should be replaced by a concrete example", and IMHO that's the difference between them and broken/unwritten code.

At least with pseudocode, it may be the right logic/train-of-thought, just that it's not something that we can run through a compiler/interpreter. Or in other words, right idea, just no implementation yet... The next level is with hypothetical or stub code: so maybe the implementation from the pseudocode compiles now, but there's too little 'meat' for us to properly discuss about potential edge cases, or performance improvements.

That's why, given my understanding, these three reasons do not belong to the same category as broken/unwritten code.

TL;DR

• Broken and unwritten code.
  • For the purpose of reviewing code, code that does not do what it's meant to do is no better than code that's not written yet.
  • Meat analogy: one is rotten meat, the other is no meat. In both cases there's nothing to eat, no dish.
• Broken/unwritten vs pseudocode, hypothetical code, and stub code.
  • The latter should be replaced by a concrete example, whereas there is figuratively nothing to see and replace for the former.
  • Meat analogy: the latter can be made meatier to sate our code review appetite, whereas there's nothing one can do to turn rotten or absence of meat into a dish.