14
\$\begingroup\$

I came across this question in my "close votes" review queue: Block_breaker clone in pygame with simple edge detection

And noted that the close reason given was:

Other: I'm voting to close this question as off-topic because I think it would be better if you spent more than one day on this before asking us to review it.

Is this a valid close reason?

As far as I can tell the code to be reviewed is in the question, it works to the best of the OP's knowledge (barring some comments to do with indentation and missing assets in the linked repository, which the OP has then acknowledged and fixed) and I'm struggling to see why it popped up in my close review queue at all.

\$\endgroup\$

6 Answers 6

14
\$\begingroup\$

I was the close voter.

After some back-and-forth with the OP, I was eventually able to get the code to run, and I started writing a review, but after a bit I gave up, because the whole program is shoddy from start to finish. Everything about it shows a lack of care and attention. It seems to me that the OP was capable of doing better than this, and it was a waste of my (or any other reviewer's) effort in helping someone who had not yet made their best attempt.

The OP states in the first sentence of the post:

I tried to make this clone of brick_breaker on my own in one day.

Clearly a day was not long enough.

(Just to make it clear, I see nothing wrong with bashing out some code to meet a self-imposed deadline. What is wrong is asking other people to review it in its shoddy half-finished state, instead of making it as good as you can and then asking for review.)

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Hi, thanks for the clarification! I think then I am inclined to agree with you, and this confusion is an unfortunate side effect of the brevity of custom close reasons. \$\endgroup\$
    – Nick Udell
    Commented May 26, 2015 at 15:23
  • \$\begingroup\$ @NickUdell: Yes, I guess I should have explained myself less concisely. \$\endgroup\$ Commented May 26, 2015 at 15:24
  • 8
    \$\begingroup\$ "What is wrong is asking other people to review it in its shoddy half-finished state, instead of making it as good as you can and then asking for review." - I agree with this whole heartedly. \$\endgroup\$
    – RubberDuck
    Commented May 26, 2015 at 15:38
  • 2
    \$\begingroup\$ Writing the Code in One day is acceptable, but then do a self-review. is my formatting proper? are there edge case bugs that will crash my game more than xx% of the time? etc. Code it the first day, accomplished, test it the second day, fix it the third day, post for review the fourth day. \$\endgroup\$
    – Malachi
    Commented May 26, 2015 at 15:44
  • \$\begingroup\$ i removed extra intend in my code and added github link. \$\endgroup\$
    – piyush_dev
    Commented Jun 30, 2015 at 13:54
13
\$\begingroup\$

I think two things are important to note here:

  1. the question is not closed - only one person has voted with that close reason
  2. you can vote to "leave open".

This is the system working the way it is supposed to work. Someone sees a problem, uses a custom close reason, and votes to close. Only if others in the community agree with that close reason will that close reason be applied to the question.

Did you vote to "leave open"?

In a sense, this meta question is being asked "too soon"... and should only be asked if the community has already closed the question.

As an aside, the custom comment would not normally be appropriate for a close reason, I agree, but in this case (and partially because this question is brought up on meta, and because our "top answerer" in the past 30 days (and 2nd all-time) is the person who voted to close, I have looked more carefully at the question....

I believe the close reason reflects what is a somewhat accurate interpretation of what we consider to be off-topic for this site:

Do I want the code to be good code? (i.e. not code-golfing, obfuscation, or similar)

in this case, the opening sentence for the question is:

I tried to make this clone of brick_breaker on my own in one day.

Is that "wanting the code to be good code"?

I downloaded the code, I pulled the "rar" file of resources. The code works, mostly. Enough for me to say it passed a "sniff test", but I can also say that the review is not being asked for in the spirit of this site. We hope for people to produce their best work, which we then review, not for people to throw stuff together in a hurry and ask us to be the "gatekeepers" of sanity.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Thanks for the in-depth answer. I hadn't considered the "Do I want the code to be good code" litmus test. I had voted to re-open but was wondering if I had done so erroneously when I saw the high rep of the closer. \$\endgroup\$
    – Nick Udell
    Commented May 26, 2015 at 15:21
10
\$\begingroup\$

Many of the best reviews on the site have been written by Gareth Rees. His answers are consistently accurate and thorough. I have full respect for his technical judgement.

That said, I'm skeptical about voting to close a question with "the code was produced in a rush" as the reason given.

There are many real-life situations that necessitate quick (or even quick-and-dirty) solution: interviews, contests, shipping deadlines, family obligations, etc. We would all like good code, but often have to settle for good-enough code, given the constraints. A self-imposed deadline isn't necessarily unreasonable.

The issue becomes whether "I think you could have done better" is a valid reason for closure. Again, I think not. Using a close vote for a question that hasn't quite violated our rules feels abusive. "The code is obviously shoddy and doesn't really work" could be a valid reason. On the other hand, if the code isn't obviously broken, then I think that the faults can be pointed out in the form of an answer, rather than in the form of a close vote. It doesn't need to be a thorough review of the kind that Gareth Rees usually writes. A good answer could just point out one or two major faults, declare that the rest of the code isn't worth looking at, and recommend going back to the drawing board.

Another way to express disapproval would be with a downvote and a comment. Neither of those actions is subject to stringent guidelines.

\$\endgroup\$
1
  • \$\begingroup\$ I came here just now to give more or less this answer. ++ \$\endgroup\$
    – RubberDuck
    Commented May 26, 2015 at 23:00
9
\$\begingroup\$

I'm a little on the edge for this question. For one I can definitely understand the reason given for the close-vote, on the other hand nothing's glaring wrong with that question (and it does have +9 | 0 score at the time of writing).

I think it's important to state here, that we do not (and should not) close questions, just because code was written in a short amount of time.
But we should close questions that violate our rules.

Often some of these rules have a correspondence in the time taken for writing and testing and cleaning and the likelihood of a violation:

Bugs often are a result of not taking the time to properly test code. Quite often you can spot glaring issues and things that could be solved better if you revisit your code after letting it sit for a while. As such it's definitely appropriate to say:

Code written in a hurry is not as clean as code written without time-constraints.

Now is code written in a hurry a violation of our rules?

I'd say no. Closing for that reason is not correct.

On the other hand, we still have following question in our help center, which IMO rules out this particular question and the manner in which it is written:

Do I want the code to be good code? (i.e. not code-golfing, obfuscation, or similar)
[highlight by me]

And I'd say a whole game, written in a day, doesn't aim for code to be good code. It's a challenge to create functionality over taking care of code. And as such I consider this question off topic.

I have accordingly voted to close this question, albeit with a different formulation as "other"

\$\endgroup\$
8
\$\begingroup\$

Whilst for someone like Jon Skeet, making a simple script here and there might take a few minutes to type out, for a beginner, this might take a few days to even understand.

The close voter must remember that people come here to seek review of their code. Whether or not the code is complex is an entirely different situation.

If the code is really basic, the tag can be added, and the review can be tailored towards beginners.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ +1 for walking in their shoes \$\endgroup\$
    – Unihedron
    Commented May 26, 2015 at 14:36
5
\$\begingroup\$

I too was wondering about this question, but I also know there are plenty of users that are familiar with the rules of the site and with Python.

as I am a Novice with Python, I chose to skip that and let the Python users handle this issue. which is what you should do if you are unclear about whether or not it should even show up. from what I saw, the code was Edited over and over again because there were bugs in the code that kept it from running, I would have voted to close it as well had I tried to run the code and it wouldn't compile, but I have no way of testing the code at the moment.

The main reason for the close vote is the fact that the code isn't ready for a review, the user hasn't taken the time to work out simple bugs, it is not working to the best of their knowledge.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ My confusion here is that, as of the time of the close vote there was no mention of problems in the comments beyond a missing file in the repository. The code in the question itself (which is all we should be reviewing anyway) appears to not have any further issues, but like you I'm no Python expert. Good point on just leaving it to the Python users to handle it, it'd be great if a Python expert could come in here and say what is wrong with the current state of the question. \$\endgroup\$
    – Nick Udell
    Commented May 26, 2015 at 14:34

You must log in to answer this question.

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