What details should always be given for a code golf task?

Ok, I just tried solving Finding subpalindromes where input and output are given in a sort of haphazardly fashion. In particular, it isn't obvious whether input is given without or with the quotes and whether output must be in exactly the formst given or whether that's all just convenience notation to show where strings start and end. In my own task I tried specifying both input and output in great detail which arguable takes more space but (imho) makes the task clearer.

That's just one example, but any task where details need to be asked before being able to solve it accurately might need a bit work beforehand, I think.

So, generally, what I'd like to see for Golf tasks would be:

• A description of what the solution is supposed to do.
• A specification how input is provided and in what format. E.g. whether input is provided on stdin or as argument to a subroutine. It's ok if there are exceptions and concessions for languages without stdin.
• A specification how output is provided and formatted. Same as above.
• A clear winning condition (we had that already in another question; just for completeness here), such as shortest code.
• A list of disallowed techniques or languages (as much as I don't particularly like that, some may deem it necessary and crying »Golfscript wasn't allowed; I'll change the question.« after a solution in Golfscript was posted isn't going to help, I guess). Of course, some common sense applies. Answers such as this answer on 99 bottles of beer don't have to be explicitly ruled out, I guess.

Of course, a reasonably complex task at hand may provoke questions not anticipated but those often cover specifics of the task, not technicalities of the solutions or the execution environment. What I'd want to avoid is that every task has the same questions as comments underneath that ask for how input or output should be provided, &c.

Thoughts? Did I miss something important? Am I trying to impose too many rules on how this should work?

• Could this be added as a checklist or outline in the question form? – luser droog Feb 21 '13 at 7:21

Extract from the code-golf tag wiki on SO:

There should be a complete, unambiguous specification of the problem. It must include at least:

• How should the answer be presented — should a bare function be acceptable, or it must include full input/output code? (meta discussion)
• The input format.
• The output format.
• A clear description of how the input and output are related.
• Explicit statement of any error checking or recovery that should be performed (because fragile solutions are, well, par for the course)
• Example inputs and outputs.

You, the asker, should be able to answer the code-golf problem (even if it's not optimal), to show that it is not a homework problem. If possible, post your solution as an answer. (meta discussion)

All popular programming languages should be allowed. (meta discussion)

A good code-golf should:

• Be thoroughly specified
• Be simple enough to be understood fully in two quick readings of the spec
• Be complex enough to admit more than one reasonable way to accomplish it,
• Have built-in-to-some-languages solutions excluded (i.e. no eval for arithmetic parsers and the like)
• Not be optimized for one language or one class of languages
• Not be too closely related to others we've done recently
• Solve a class of problems rather than a single instance
• Oh nice. Definitely agreed :-) – Joey Jan 30 '11 at 19:52
• The last list looks a lot like one of my posts on meta.SO, and I stand by it as a default. That said, this specialized site can probably support variations. In particular there may be room for an occasional problem that is more complicated that described above. – dmckee --- ex-moderator kitten Jan 30 '11 at 20:40
• @dmckee Agreed. I think we could spawn a few more meta threads to discuss some of these points as time goes by. Then we can edit in links to those discussions here. – moinudin Jan 30 '11 at 20:45
• One thing that bugs me is when you have to follow a link to see the problem specification. I think there should be a rule agin' it. – Joey Adams Feb 2 '11 at 3:56
• @dmckee & all: why don't we just adopt @dmckee's excellent [accepted answer]((meta.stackoverflow.com/questions/24242/…)) from SO? – MtnViewMark Feb 20 '11 at 17:09
• @MtnViewMark: At a minimum we'd want to drop the CW requirement and rate limitation. Also the warning to low rep users. – dmckee --- ex-moderator kitten Feb 20 '11 at 17:13

It might be useful to have a suggested template for golf questions in our FAQ.

Should STDERR be ignored?

If STDERR ouput is ignored, the program can halt by raising an exception or crash.

• It can be piped to /dev/null, so my answer is yes. – moinudin Jan 30 '11 at 16:40
• Indeed, something I have used every now and then already. Allows Java to put all code into a static initializer instead of main() ;-) – Joey Jan 30 '11 at 18:06
• @Joey: enum C{C;{...}} is a fair amount shorter ;) – Nabb Feb 3 '11 at 7:56