1. **Subjective scoring criteria:** Challenges must have objective scoring criteria. Competitions for the  *cleverest*, *nicest*, or *best* are off-topic.
1. **Problems without solutions:** Please solve your task before posting it, to ensure that it can in fact be done.
1. **Saying *random* without specification.** Always specify if whether you mean a random member of a fixed set or whether all possibilities must be able to happen, what distribution(s) you allow, etc.
1. **Special treatment of edge cases:** If you really must include edge cases in the input domain, avoid special rules. E.g. if the task is to count the occurrences then do not require the value `-1` (rather than `0`) if none are found.
1. **Misleading specifications:** Do not describe a simple task, only to follow it with "but wait, there's a twist". Instead, be upfront about what the task is.
1. **Multiple return types/behaviours depending on a condition:** Some languages require a consistent return type, and some cannot throw errors etc.
1. **Requiring validation of input:** Either promise that input will be valid, or state that undefined behaviour is acceptable for invalid input.
1. **Involving primes:** Hundreds of challenges with primality as central subject already exist.
1. **Additional tasks *for completeness*:** Do not e.g. add additional specifications for negative inputs, just to extend the input domain from positive.
1. **Allowing a default loophole,** unless exploiting the loophole is the central task.
1. **Back stories:** People are here to find coding challenges, not prose.
1. **Problematic test case formats:** JSON is often a good choice, as many languages have libraries for it. Use a table or a simple separator between input and output. Do not give a list of inputs and a separate list of outputs, or intersperse text with test cases.
1. **Tasks depending language features:** Avoid *if you language supports X, then…* or *if you language cannot Y, then…*
1. **Rules that cannot (easily) be verified:** Do not require the use of a specific algorithm or the avoidance of a specific built-in, data type, or library.
1. ***Do X without Y*:** Unless very carefully specified, it is hard to get such challenges right as language features differ wildly. E.g. are `prod()` and `×` forbidden if `*` is prohibited? Is `mod()` forbidden if division is?
1. **Multiple tasks in a single challenge:** E.g. *compute X, then do Y*. Instead, cut down your challenge to the core task or split it into multiple unrelated competitions.
1. **Extraneous information:** Include all knowledge necessary to solve the task in your problem text, but no more, and avoid linking to websites about subjects that are only tangentially related.
1. **Banning or disadvantaging (groups of) languages:** Some people dislike dedicated golfing languages, but others enjoy them, so please let them participate too. Also, avoid a task that involves e.g. the language name.
1. **Changing rules mid-game:** Someone might have found a loophole you missed, or an algorithm you didn't realise existed, but don't change the task or try to ban these after the event.
1. **Artificially setting a max code length:** Some languages are verbose, but that doesn't mean they shouldn't be allowed to participate. (An exception to this is for challenges to do as much as possible in a given space.)
1. **Quine variations:** Most quine-based tasks boil down to the same core.
1. **Advanced numeric types for no reason:** There's no reason to require floats if the same basic idea can be done with integers, etc. The same goes for complex or extended precision numbers, unless some operation involving them is the core task.
1. **Duct taping clarifications:** If necessary, amend your post to clarify matters, but don't just add bullet points to answer questions posed in chat.
1. **Extra tasks:** Boil your challenge down to its core; don't include dealing with strange input/output formats, invalid input, hard-coding large constants, or bonus tasks.
1. **Limited input domains,** where hard-coding the input-output mapping wins over actually implementing the functionality.
1. **Uneven multiple scoring criteria;** E.g. length and speed, or correctness and code length, where one relatively much harder or one can be maxed out and the tie-breaking becomes the only real winning criteria.
1. **Code golf as *secondary* criterion:** This gives an unfair advantage to terser languages.
1. **Specification by test cases:** Make sure to explain the task with formulas or in proper English.
1. **Popularity contests:** Asking for "innovative" solutions, where the goal is to gather votes, is off-topic.
1. **Specification in chat:** If you need to, amend your challenge text. Do not expect people to read through the chat log.
1. **Require, or not:** Do not say things like *try to…* or *I prefer solutions that…*.
1. **Making assumptions about language features:** Languages vary greatly. Allow both functions and programs, do not require handling pointers, throwing exceptions, or behaviour at compile time, or presume the existence of specific built-ins or types, or availability of (im)mutability, etc.
1. **Make exceptions to default rules** without a very good reason.
1. **Untestable tasks:** E.g. give a time/date as input rather than using the current time/date.