Anonymous user
Rosetta Code:Add a Task: Difference between revisions
→Things to avoid: Expand on partial solutions
(Tagging as a way to contribute.) |
(→Things to avoid: Expand on partial solutions) |
||
Line 35:
* '''Don't require exceedingly rare features.''' Requiring unique language features, or rare combinations of features, leads to the same problems as requiring a specific language.
** The caveat to the above, of course, is that '''best-effort solutions are often fine''' Some example solutions can fudge the spec without being inappropriate. ''"This isn't exactly possible in Ayrch, but something practical solving the language's idiomatic analog would be..."''
***Think carefully about adding a later partial solution to a task if a working, full solution exists.
***When giving a best effort solution then state near its top, just what aspects of the task are not implemented, to avoid later editors marking the example as incorrect.
***Consider the removal of a prior partial solution to a task when adding a new full solution to the task.
* '''Avoid creating tasks seeking the smallest possible solution.''' Code golf, or the finding of the absolute most succinct expression of a solution as its own goal, is not often an idiomatic, practical or comprehensible use of the language in question, and so is difficult to justify in a demonstrative context. Strokes are not points.
* '''Avoid creating tasks seeking the fastest possible solution.''' Optimized code is rarely easy to read, and is often exceptionally complex as something to learn from. However, provided it does not make the overall section for the language too long, users may provide a more-optimal solution as an alternative solution to a particular task so that learners can compare it to the “optimized for clarity to people” version that should be the main solution for the language. (We also do not want to see the site devolving into “my language is faster than yours” silliness.)
| |||