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

Question

Related: For Code Golf, how do you deal with languages without a traditional print/echo statements?
Related: What programming language should we consider for the code-golf solution ?
Related: Use of built-in functions and libraries in Code Golfs

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?

Answer 1

Extract from the code-golf tag wiki on SO:

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

• What kind of inputs to expect. eg. natural numbers, strings of ASCII printable letters, ragged array. Be very specific what values programs need to deal with or not.
• What kind of outputs are acceptable. Can there be multiple possible solutions? Can you output in reverse order? Can you omit the first element if it's always the same. etc.
• Input/Output format if not the same as our defaults
• A clear description of how the input and output are related.
• Clarification on any edge cases. Note: Allowing answers to assume the edge case will never happen is a good clarification. Still it needs to be specified in the answer.
• 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 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
• Admit rapid naive implementations
• 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
• See things to avoid when writing challenges for a more complete list.

Answer 2

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

Answer 3

Should STDERR be ignored?

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