5
\$\begingroup\$

Here are our current close reasons:

enter image description here

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?

\$\endgroup\$
  • \$\begingroup\$ I have a question about this as well. I voted to close a question because it had bugs in it. In my opinion, the OP would have found at least one of these bugs if they had spent even a little effort in testing. However, if the OP was not aware of any of these bugs, is the question still on topic? \$\endgroup\$ – JS1 May 20 '15 at 3:12
  • \$\begingroup\$ @JS1 feel free to post a question here at Meta about that (I know which you're talking about :)), my short take on those questions is that if the bugs are relatively trivial, then we should just be kind and point out. If the bug significantly alters their understanding of the question they were given, then that's more likely to be a close reason... \$\endgroup\$ – h.j.k. May 20 '15 at 3:13
  • \$\begingroup\$ @JS1 I don't think so...? Probably easier to ask a question here and tag it with "specific-question". \$\endgroup\$ – h.j.k. May 20 '15 at 3:15
  • \$\begingroup\$ @h.j.k. Ok I made my own meta post about that question. \$\endgroup\$ – JS1 May 20 '15 at 3:26
3
\$\begingroup\$

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.
\$\endgroup\$
  • 1
    \$\begingroup\$ Then why shouldn't broken code and pseudocode be lumped together? How does unwritten code differ pseudocode, hypothetical code, and stub code? (Most particularly in the context of choosing a close reason.) \$\endgroup\$ – nhgrif May 20 '15 at 10:28
  • 1
    \$\begingroup\$ "code that does not do what it's meant to do is no better than code that's not written yet." ++ Yes. I think that's what we mean as well. \$\endgroup\$ – RubberDuck May 20 '15 at 10:28
  • \$\begingroup\$ Although, "code not yet written" often falls under design questions in practicality. Perhaps that first close reason could be interpreted as our version of "Questions about X belong on Y." \$\endgroup\$ – RubberDuck May 20 '15 at 10:31
  • \$\begingroup\$ @nhgrif see edit. :) \$\endgroup\$ – h.j.k. May 20 '15 at 11:25
  • \$\begingroup\$ You keep tying unwritten back to broken though. You've done nothing to convince me that broken and unwritten should be under the same close reason. You answer talks more about the second close reason while this question is about the first close reason. \$\endgroup\$ – nhgrif May 20 '15 at 11:27
  • \$\begingroup\$ @nhgrif I tried to summarize my thoughts... \$\endgroup\$ – h.j.k. May 20 '15 at 12:29
  • \$\begingroup\$ @nhgrif my edits for the second close reason was motivated by your first comment, so I thought I'll do my best to clarify that part as well. \$\endgroup\$ – h.j.k. May 20 '15 at 12:31

You must log in to answer this question.

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