Rosetta Code:Add a Task: Difference between revisions
→Things to avoid: "Code Golf:" prefix
m (typo) |
(→Things to avoid: "Code Golf:" prefix) |
||
| (19 intermediate revisions by 9 users not shown) | |||
Line 1:
{{
A task has a very simple layout:
<pre>{{task}}Description of the task
...
Examples</pre>
==Prerequisites==
===Create the page===
Come up with a title for your task (look at [[:Category:Programming Tasks|the current tasks]] to see what kind of name you should choose), type it in the search bar, and click "Go". There will be a "Create page" link on the resulting page somewhere. Click that, and you can begin editing.
A few guidelines for a good task title:
* Don't be too general; make the title closely focused on describing what the task is actually asking to do.
::If your task is "Generate the lyrics to 99 bottles of beer" for instance, a good title is "99 bottles of beer". A poor title would be "Generate song lyrics".
* Don't be too specific; don't include terms that are peripheral to the task, even if it is a common term.
::If your task is "Generate twin primes up to some limit"; a good title is "Twin primes", a poor title would be "Twin prime conjecture".
* Follow some simple capitalization rules:
:# The first character of the title should always be uppercase, even if referring to something normally lowercase.
:# The first character after a level separator ( forward solidus: / ) should always be uppercase.
:# Every other word should be lowercase except for proper nouns, names and common initialisms.
* Avoid including characters outside of ASCII alphanumerics. Try to make your task title easily type-able on a standard US keyboard.
There is substantial leeway in these rules, and some are subject to interpretation, but the closer you can come to following them, the easier it will be all-around.
===Draft vs non-draft===
Not all tasks are immediately ready to be thrown at the casual Rosetta Code participant. Some need a review or draft phase before they're in good shape.
* For a non-draft task, one would use [[Template:Task]] by putting
* To note that a task is a draft, use [[Template:draft task]], by putting
It's up to you to decide which you start with, but another community member may choose to change your created task to a draft. If there is some question on the general suitability of the task then create a draft task and discuss the reason for it being a draft in the talk page. This will warn potential contributors that there may be substantial changes in the task description whilst still in draft status.
Line 30 ⟶ 55:
* '''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.
* '''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.▼
***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. For now, the only exception to this rule is [[Code Golf: Code Golf]]. If there is a case to be made for another exception, please use the prefix "Code Golf:" when creating the page.
* '''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.)
===Basic information===
Line 38 ⟶ 67:
Where relevant, '''sample input''' should be included; it gives task solvers something to work with.
If your task requires a '''wordlist''' to be used with / tested against, it may be worthwhile specifying [[Wordlists|one of the commonly used]] ones to make it easier for other entry authors to fulfil and make results more uniform so different implementations can be more easily compared.
===Example code===
It is usually a good idea to '''have at least 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, it helps other implementers understand the task and what they need to do.
In short, solve your own task. Show us how it's done.
==Additional information==▼
▲==Additional information==
===Lurk!===
'''Read existing task descriptions''', and model yours after ones you like. If you follow the Recent Changes feed, you can watch the creation of one, live. Alternately, you might take a look at the edit history of existing tasks (and their talk pages), to get a feel of the process and the (unwritten) "house style."
Line 60 ⟶ 82:
===Jargon===
It helps to '''explain jargon''', as about the only common jargon that's likely be understood would be in the fields of programming or computer science
===Extreme Language===
Some schools, libraries and parental filters filter pages whose URLs match wordlists. This even occasionally impacts Rosetta Code's reCAPTCHA API key. We try to include this audience, so please [[wp:bowlderise|self-censor]] such content. (For an example, see the discussion page for language [[Category talk:Brainf***|Brainf***]]).
| |||