Anonymous user
Rosetta Code:Add a Task: Difference between revisions
→Basic information
Line 8:
As languages are the richest resource of comparison on Rosetta Code, a task should not be so specific as to invoke a particular language as being the only one allowed to solve a task. A task should also not be so specific with its other requirements that there is only one language capable of solving it. Best-effort solutions ("this isn't exactly possible in Ayrch, but something practical solving the language's idiomatic analog would be") are often fine, so a task writer may find that styles "use technique X to solve problem" and "solve problem using technique X" may need to be interchanged to make a useful number of solutions possible.
===Basic information===
* A simple description of the problem.<br> having a solution to the task allows you to tune the task description so that the size of outputs or run times are reasonable.
* Inline references to specifically-related information.<br>Although links to offsite information do help in a task description, it is best to have enough of a description of the task on the R.C. site itself.
* Sample input
===Example code===
* At least one example implementation.<br>It is usually a good ides to have this one example implementation completed, tested, and working ''before'' you start writing the description of the task, as well as a sample of correct output. It is usually a good idea if this first example shows its output even if it isn't strictly necessary for the completion of the task as it helps other implementers.
| |||