Acceptable level of code golf questions? [closed]

Question

As a forward, this is not about whether or not code golf is valid on Stack Overflow. If you argue against this, you're arguing against a mound of evidence, and you should be arguing in the other questions about this topic.

Most people (myself included) seem to be of the opinion that code golf questions, in and of themselves, are acceptable. Most people (again, myself included) also seem to be of the opinion that there is a certain frequency at which there are too many code golf questions being asked too quickly, or of "too low quality." Also brought up is whether or not low-reputation users should ask code golf questions, as they are not as well established in the community (which is the entire point of code golf).

So, in light of this, I suggest we discuss (and hopefully establish) a rule or guideline concerning the asking of code golf questions. Post answers suggesting metrics you think should be used to govern code golf, and upvote answers that you think are best. That way, we'll get a community consensus on what is "too much" or "too low quality" code golf.

Points to address (reiterated to put them all in one easy-to-grok place):

• How far apart, time wise, should code golf questions be? What frequency of code golf questions per your favorite period of time do you think is an acceptable maximum?
• How should the quality of a code golf question be evaluated? Should quality be an important factor in determining whether or not a code golf question is allowed? (Note: I know this can easily be subjective, but all the rules about what is "appropriate" for code golf are subjective. Just because it's subjective doesn't mean we can't get good guidelines or ideas on how to answer it.)
• Should the asker be taken into account when evaluating a code golf question for appropriateness? What guidelines should be used for that?
• What actions, if any, should (or can) be taken to inform new users about code golf rules?

EDIT: Add this:

• What are the minimum specification requirements for a code golf question? I don't think this is subjective, because it's impossible to answer a code golf question without knowing certain things, so this one shouldn't be easy. However, it is a separate issue from the quality discussed in point 2. That point is intended to deal with the quality of the challenge, not the quality of the challenge's specifications. I think should separate "well-asked code golf" from "good code golf" and evaluate (and treat) each separately. If you disagree, of course, say so.

Answer 1

Frequency:

Too many code-golfs too fast, distracts from the main mission of the site and from the attention that can be paid to each contest. Please don't post if your question would be the third one in any given seven day period

Non-negotiable requirements:

• Community wiki
• An indication of what the winning criterion is, either "shortest code" or "shortest source code"
  • The choice of wording allows the question poster to decide if object code entries (machine code, bytecode, etc.) should count.
  • If the winning criterion is something other than code brevity, then it's not a code golf, and the code-challenge tag should be used instead.

Quality: A good code golf should

1. be thoroughly specified
2. be simple enough to be understood fully in two quick readings of the spec
3. admit rapid naive implementations
4. be complex enough to admit more than one reasonable way to accomplish it,
5. have built-in-to-some-languages solutions excluded (i.e. no eval for arithmetic parsers and the like)
6. not be optimized for one language or one class of languages
7. not be too closely related to others we've done recently
8. solve a class of problems rather than a single instance

I'm not going to answer the second half (should quality effect closability) because I feel that I've said my piece already.

Low rep users:

New users are strongly discouraged from posting code golf questions until they fully understand the specific circumstances under which these challenges are considered appropriate. You have been warned.

Specification:

Good thing to specify:

• should the solutions be bare functions or complete programs?
• input spec.
• output spec.
• a clear description of how the input and output should be related
• explicit statement of any error checking or recovery that should be performed (because fragile solutions are, well, par for the course)
• test inputs with expected output

Things you are discouraged from specifing:

• limits on or description of the process that should be applied to get from input to output

Links

Please include an advisory link to this question.

Tags

The usual tags for code golf questions are

code-golf rosetta-stone language-agnostic

and possibly something relevant to the problem posed

Answer 2

Okay, Chris beat me to posting it here.

But I prepared this for my 'complain' for the recent code golf bomb.

_{(source: liranuna.com)}

Marked in yellow are my questions. Blue are 'other users'. The reason the challenge Seven Segment was ranked relatively low was because I added a rule where you cannot use eval or system, mainly to prevent the use of figlet. But people seemed to hate restrictions, so now I design my questions to not impose limitations, like Lasers, which I consider highly successful.

Answer 3

I'm only going to pose one question as an answer to one of the points: When is Jeff adding "Reason for closing: Already too many code golfs this week"?

You can subjectively up/down-vote or vote to close a code golf on any other merit*, but you can't police the community on how frequently code golf questions are asked.

* Might be neither here nor there, but I'll agree that the code golf I posted was fairly shitty. It sounded good in my head, but after I actually wrote it out it was clear how poor of a question it was. I'd just as soon have the question deleted, frankly, but I don't think that can happen with how many answers there are already.

Answer 4

I'd prefer no code golf, but since that's not an option...

As many have pointed out, code golf needs to be limited in frequency. Also needs to be of a given quantity. I really don't see a way for that to happen naturally in the site. That's the type of thing that truly needs to be moderated. Code golf items should be submitted for approval, then released by a moderator (if appropriate) at a "reasonable" interval.

Answer 5

How far apart, time wise, should code golf questions be? What frequency of code golf questions per your favorite period of time do you think is an acceptable maximum?

There is no maximum, if the questions are quality ones.

How should the quality of a code golf question be evaluated?

If it survives community scrutiny without getting closed, it's a quality question.

Should the asker be taken into account when evaluating a code golf question for appropriateness?

Absolutely not. Do you look at a user's profile before you upvote or downvote them?

What actions, if any, should (or can) be taken to inform new users about code golf rules?

If these rules become part of the Official FAQ, you can post a link to the Code Golf FAQ in a comment to the OP.

Answer 6

We seem to have a really good answer from dmckee, and I agree with almost anything he said, so reposting all his answers is fruitless. However, I would like to add:

• What actions, if any, should (or can) be taken to inform new users about code golf rules?

I think (this is me) that this question, with dmckee's answer probably accepted fairly soon, should be part of the FAQ if possible. I also think that code golf questions (preferably all) should link to them, like this:

See the Stack Overflow unofficial policy on code golf before posting your own code golf.

Sort of how the system edits questions to contain "Cosed as duplicate: [link]" when they're closed, only I wouldn't want to bother Jeff to add to the system, so it can be self-enforced. Hopefully this way, no one will read a bunch of code golf questions and think "I'm gonna make my own!" without seeing the link to the (un)official guidelines that we expect them to follow. I think that will help keep the number of code golf questions reasonable and keep the quality high. If they're all supposed to be Community Wiki anyway, it's fairly trivial to edit that line (or some variation) into code golf questions. That way, anyone who enjoys code golf will have no excuse for not knowing what Stack Overflow users expect from a code golf question.