113

Cumbersome I/O formats Generally, allow flexible input and output formats. People want to write code to do your task of, say, composing permutations, not reading/writing numbers in a particular semicolon-separated format, or from a file, or with input validation. For code golf, it's annoying when most of your byte count is boilerplate, especially when other ...


78

Rules inferred from test cases Test cases are examples for people to check their understanding of the spec and the correctness of their code. They should not replace an explanation of how the output must relate to the input. (There are rare exceptions where it's straightforward, like a scaling ASCII art pattern.) Don't leave readers guessing as to what the ...


71

Explicitly disallowing or disadvantaging arbitrary (classes of) languages This has become much rarer recently, but the occasional challenge by a new user still includes it, so here as an answer to point them to. Disallowing arbitrary languages (or classes of languages, primarily things like "no golfing languages allowed") is not in the spirit of this ...


71

Making assumptions about language features Unless you're writing a language-specific challenge, avoid terms specific to some class of languages, because these might not make sense for other languages and prevent them from participating. Languages can very different from what you're used to: functional, minimalist, graphical, untyped, strongly typed, and ...


71

Do X without Y This isn't always bad, but it's been a particular trap for beginners, so be careful. In the past, there were popular questions about doing a simple task but with the obvious method banned: Produce the number 2014 without any numbers in your source code How to write a C program for multiplication without using the * and + operators? Add ...


67

Changing the challenge in the comments If something was unspecified in your challenge, or if you've decided to make a change to the challenge (Such as to close a loophole), don't just leave a comment. These are often not visible unless you click on the correct button, and will lead to people getting confused. Instead, edit the challenge to incorporate the ...


67

Bonuses in code golf Digital Trauma wrote an answer about this, but I have harsher views on bonuses, so I'm posting to let people vote separately. Bonuses in code golf say things like "-30% of your byte count if your code can handle any number of strings, not just two." From what I've seen, they range from slightly improving the challenge to seriously ...


58

Putting test cases in a hard to use format Supplying test cases is always a good idea, but people are more likely to use them (and thus have better tested code) if they can easily be copied and pasted into a test suite. So format your test cases as simply and as consistently as possible, preferably in a single code block. If you have lots of test cases and ...


56

Requiring minimum scores In short, don't post a code golf that says "Your code has to be shorter than 100 bytes" (the same applies to any other winning criterion). The usual motivation is that the author found some code somewhere and challenges people to beat the score of that code. That's a fine motivation for a challenge, but actually requiring all ...


52

Chameleon challenges Chameleon challenges look like they're about one thing but are really about another. In doing the challenge, most of the effort is spent on something peripheral. Fix this by being honest about your challenge in the title and description, or by simplifying or removing the non-core parts. Some causes of chameleon challenges: Requiring a ...


49

No, invalid inputs may result in undefined behavior Requiring input validation only adds extraneous code to the answer and takes away from the challenge.


47

Don't allow / ask for different things in languages with different capabilities Don't write specs like "Do X. If your language doesn't support X, you can do Y instead". Examples are: Do some math in floating point. If your language doesn't support floating point, you can use integer Read input from a file. If your language doesn't support file I/O, you can ...


46

Non-observable program requirements The validity of a program should depend on things that can be observed when the program is treated as a black box. Examples are data written to standard output or error streams, drawing on the screen, file operations, memory usage, and runtime. Non-observable behaviors include "string operations" and "...


41

Requiring the use of unnecessarily "complicated" number types A large proportion of our challenges deal with numbers, or lists of numbers. An important consideration is always what sort of numbers are valid input (positive integers, non-negative integers, all integers, floating-point numbers, complex integers, complex floating-point numbers...). In the ...


40

Arbitrarily overriding the defaults The default code formats, input/output methods, and other defaults are a product of community thought and discussion. Don't change them just because you feel like it or disagree with them. They have good reasons for being as they are, some of which are only apparent for specific languages that would otherwise be unusable ...


39

"Ideally, your code will..." Avoid recommended features in your spec. If it's not mandatory, answers won't do it. The goal is to write the shortest/fastest/winningest code that still satisfies the requirements, however minimally, so any features that can be cut or simplified will be. Of course, popularity contests are an exception.


38

Saying you should produce one or several outputs randomly without further specification One random output Say someone writes a challenge about generating a labyrinth of a given size (width and height) taken as input, and they say that you should create a randomly arranged labyrinth of that size. What does random mean here? As it has been specified, you may ...


37

The prime numbers We have 226 questions about prime numbers at the time of writing. Almost every single one of these involves some adaptation of the “canonical prime checking code” or the “canonical prime generator”. Primes are notorious for not really conforming to any mathematical symmetry in a lot of ways, so very often, there is no way around a “brute ...


35

Most kinds of generalised quines Quines continue to fascinate this community... but we already have a plain quine challenge so we're "forced" to innovate by making quine-related challenges that aren't pure quines. For the purpose of this post, I'm defining a generalised quine as a program P which prints F(P), where F is some function of a string. (E.g. "...


35

Formulating the challenge as something and then including a twist that completely changes the task Don't hide information from the reader. Don't enounce the challenge as something that later on it will turn out not to be. To ellaborate, consider the following formulation: Do < task A, usually easy, described in one or several paragraphs > But wait! / ...


34

I think that, as a general policy, if we see a challenge that is clearly homework, we should leave it open without complaint (perhaps even upvote it or leave compliments on the excellent question), but any requested language should be ignored and all answers should be written in Befunge or Brainfuck.


34

Allowing standard loopholes in general Don't say "Standard loopholes are allowed". They ban silly things like making up a language where the solution is a single character or just printing the string "the answer". Even if you find these amusing, we got tired of them long ago and that's why they're forbidden. Allowing specific loopholes, such as fetching ...


33

Patching out approaches On your challenge, someone posts a solution that's cheap and not at all what you intended. You have the option to change the rules, but do so very carefully as there's many pitfalls. Don't: Criticize the answerer. They were just trying their best towards the winning criteria as stated. Simply encourage avoiding this approach. If it's ...


33

Adding unnecessary fluff See also: Chameleon challenges, Cumbersome I/O formats, Do X without Y What's the main point of the challenge? Try to keep the challenge to just that. Don't go adding frills to the challenge just because it "looks too easy", or inserting strange modifications to a perfectly okay challenge just to "make things interesting". Keep it ...


28

Input Validation This is a subset of adding special cases for completeness that seems to come up pretty often. From a given set of possible inputs, a solution shouldn't have to sort out inputs that don't apply to the challenge. For example, imagine a challenge that asks to find the index of a value in a sequence. For values that are not in the sequence, or ...


27

Keep It, but... ...we should definitely update e.g. the tag info. The recent discussions have not been unproductive, and I think we have better guidelines than ever before but at the moment they are still all buried in meta questions/answers. Example: As far as I know it is the first time that the term validity criterion emerged so clearly which definitely ...


26

Popularity Contests Popularity contests, while allowed, are heavily disfavored by site culture. You're likely better off reworking your challenge to use an objective winning criterion that isn't votes, such as code golf or fastest code. That is, unless you're an experienced user who knows when to disregard such advice. Of the last 15 pop-cons as of writing,...


22

Narrow references Beware of challenge topics that tickle your fancy, but others won't appreciate. An in-joke among friends A reference to a movie you like A task from actual code you wrote A small part of an existing algorithm without context These can be sources of inspiration, but make sure the challenge itself is interesting to do. Imagine someone ...


Only top voted, non community-wiki answers of a minimum length are eligible