8
\$\begingroup\$

Following up on a past discussions, I'd like to tweak our list of off-topic close reasons. We may have up to three canned reasons. Currently, they are:

  1. Questions asking for code to be written to solve a specific problem are off-topic here as there is no code to review.

  2. Your question must contain working code for us to review it here. For questions regarding specific problems encountered while coding, try Stack Overflow. After getting your code to work, you may edit this question seeking a review of your working code.

  3. Questions must include the code you want reviewed. Code must not appear only in a link to an external source. Doing so makes us dependent on a third-party site and makes it harder to review your code. If your code is very large, please select only the portions in which you are especially interested in for a review. You are welcome to keep the link to the rest of your code.

I've posted a proposal below. Upvote it, or post your own counterproposal.

\$\endgroup\$
12
\$\begingroup\$

My proposal:

  1. Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. Such questions may be more suitable for Stack Overflow or Programmers. After the question has been edited to contain working code, we will consider reopening it.

  2. Questions must include the code to be reviewed. Links to code hosted on third-party sites are permissible, but the most relevant excerpts must be embedded in the question itself.

  3. Questions must involve real code that you own or maintain. Questions seeking an explanation of someone else's code are off-topic. Pseudocode, hypothetical code, or stub code should be replaced by a concrete example.

\$\endgroup\$
  • 1
    \$\begingroup\$ I like that you're linking to meta posts and to the sites' respective on-topic pages. \$\endgroup\$ – Mathieu Guindon Apr 1 '14 at 20:22
  • 1
    \$\begingroup\$ The repetitiveness in #2 bothers me. Can anyone devise a less redundant wording? \$\endgroup\$ – 200_success Apr 1 '14 at 20:25
  • 1
    \$\begingroup\$ How about "Questions must include the code to be reviewed. Links to code ...." That way it's also a parallel construction to the other two. \$\endgroup\$ – Edward Apr 1 '14 at 20:33
  • \$\begingroup\$ @Edward Thanks. Incorporated in Rev 2. \$\endgroup\$ – 200_success Apr 1 '14 at 20:35
  • \$\begingroup\$ Looking good, fixed a typo in rev 3 :) \$\endgroup\$ – Simon Forsberg Apr 1 '14 at 20:36
  • \$\begingroup\$ I would somehow like to incorporate "questions about altering what the code does" in #1, or elsewhere somewhere. Considering this question and a lot of questions similar to it. \$\endgroup\$ – Simon Forsberg Apr 1 '14 at 21:24
  • \$\begingroup\$ Looks very good to me. After you set up the final product, I'll approve them (it takes two mods to make a close reason change). \$\endgroup\$ – Jamal Apr 1 '14 at 21:52
  • \$\begingroup\$ What's the difference between #1's "code not yet written" and #3's "hypothetical code"? I just voted to close a question, and both #1 and #3 seemed applicable for it. User had sketched out (in code) what he might do. So, in my eyes, it was hypothetical, not yet written, and pseudo-ish all in one. \$\endgroup\$ – Flambino Apr 24 '14 at 21:51
  • \$\begingroup\$ @Flambino By hypothetical code, I mean code that has been completely stripped of its context, e.g., code where functions are named foo(). Can you suggest a better label for such code? In the end, a closure vote is a closure vote, whichever reason you pick. The only difference is whether you want to tell the author to "finish writing your code first" or "replace generic code with concrete details." \$\endgroup\$ – 200_success Apr 24 '14 at 21:59
  • \$\begingroup\$ Oh, I know a vote is a vote, I just did a double-take on the wording and started wondering. Honestly, I still don't know what I'd tell the author; the code in question was technically valid and concrete, but it didn't sound like it'd actually been tried out. So it's a hypothetical solution with concrete code. Hence why I found it a little hard to pin down. \$\endgroup\$ – Flambino Apr 24 '14 at 22:26
  • \$\begingroup\$ @Flambino When nobody is really certain of anything, a custom close reason would be preferable to tell the author exactly what is on your mind. A crude canned message based on a wrong assumption could be the start of a nasty disagreement. \$\endgroup\$ – 200_success Apr 24 '14 at 22:38
  • \$\begingroup\$ Good point; I just picked #1, but added a comment to the question to explain further. And I see you put that particular question on hold with an informative message, so it's all good. \$\endgroup\$ – Flambino Apr 24 '14 at 22:47
6
\$\begingroup\$

We only have three custom options. I believe we can be more efficient with the close reasons...

:

  1. No Code:

    • Code is not included or is only a link
    • Code does not exist (a request for design help)
  2. Code is included but the included code:

    • has severe bugs which are obvious
    • does not yet contain the features that are requested in the review
  3. Question contains code, but the question is about general design or opinion:

    • the code is pseudocode, or stub code illustrating a design pattern or model
    • opinions on Best Practice in general, or 'choosing' between alternatives
    • getting opinions on someone else's code

These issues are not very different from 200_success's suggestions, but I would re-formulate the close reasons on the above categories

  1. Your question contains no code to review. Your question must have code embedded to be reviewed. Specifically, Code Review cannot rely on third-party hosts to maintain the consistency and availability of code. If the code does not exist yet, and you are looking for design help, then Programmers is the place to ask.

  2. Your code does not work as designed. Your question has significant bugs, or it is missing required features, and these need to be resolved before the code is ready to review. Stack Overflow is the appropriate place to ask about errors in your code. When your code works as designed, feel free to bring it back for review.

  3. Your question is seeking opinions on Best Practices. Your code is example code, pseudo-code, stub-code, or someone else's code. It does not represent your actual code in a working system.

\$\endgroup\$
  • \$\begingroup\$ I've incorporated wording from your reason #3 the other answer. \$\endgroup\$ – 200_success Apr 2 '14 at 4:55
  • 1
    \$\begingroup\$ "Your question has significant bugs"? \$\endgroup\$ – Simon Forsberg Apr 2 '14 at 8:04

You must log in to answer this question.

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