Rosetta Code:Add a Task: Difference between revisions

→‎Prerequisites: Group and rename inclusion/exclusion
(→‎Task focus exclusion: Bullet again.)
(→‎Prerequisites: Group and rename inclusion/exclusion)
Line 16:
* '''The task is too specific,''' implementable by too few languages.
 
===Task focus inclusion===
 
====Things to try for====
Generally speaking, '''the goal is to address a problem a programmer may face or want to think about.''' These include (but aren't strictly limited to):
* Practical problems
* Problems which demonstrate concepts
* Simple entertainment.
 
As for discouraged areas, remember that Rosetta Code is a tool of education, not a code repository. "Code golf", or the finding of the absolute most succinct expression of a solution as its own goal, is rarely idiomatic or practical use of the languages in question, and so is also difficult to justify in a demonstrative context.
 
The common theme across all tasks must be increasing competence and understanding of the tools in question, by example or by annotated counterexample if necessary.
 
===Task=Things focusto exclusionavoid====
* '''Don't require a specific language.''' Tasks which specify a particular language will not tend to achieve many useful comparisons or solutions, as languages are the richest resource on Rosetta Code. If your personal goal is to create a task which highlights a feature of a particular language, where that feature is unique or extraordinarily rare, don't create a task where that feature is ''required'' to solve the task. Instead, create a task that can be solved using a variety of means, but where that feature can greatly help in solving it. You may wish to highlight a unique feature of a particular language (yes, there are specific language advocates on Rosetta Code, and that's fine), but nobody will see that feature's usefulness if there are very few other languages for them to compare against.
* '''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 '''Bestbest-effort solutions are often fine''' A caveat to the above notes is that someSome 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..."''
As* for'''Avoid discouragedcreating areas,tasks rememberseeking thatthe Rosettasmallest Codepossible is a tool of education, not a code repositorysolution.''' "Code golf", or the finding of the absolute most succinct expression of a solution as its own goal, is rarelynot often an idiomatic, practical or practicalcomprehensible use of the languageslanguage in question, and so is also difficult to justify in a demonstrative context. Strokes are not points.
 
===Basic information===
A task needs a few basic components. It neeedsneeds a '''simple description of the problem'''. Having a solution to the task allows you to tune the task description such that the run times and/or size of outputs are reasonable.
 
'''Inline references to specifically-related information''' are important. While offsiteoff-site links are often necessary (if only for appropriate citation), enough cited, excerpted information should be included such that the task may still be solved.
 
Where relevant, '''sample input''' should be included; it gives task solvers something to work with.