# Is it okay to write a challange that has an obvious output?

Assume the challenge:

Print any prime n whose n-1 is also a prime.

It's obvious that 3 is the only output. However, specified in the rules:

Hardcoding 3 as output is forbidden.

Does it make any sense to ask these kind of questions, that will make the code calculate something, but for no reason?

• I can't find the meta post that disallows these, but you'll get flooded with downvotes. (perfectly reasonable IMO) Dec 25 '16 at 23:16
• Disallowing hardcoding is a huge red flag. For a start, what counts as hard coding. Can I return 2+1? What if I make the computation more elaborate. Where does it stop being hardcoded? Furthermore, any restriction like this on available approaches is a non-observable program requirement, which means you can't determine whether the rule has been followed just by running the program with various inputs and observing its behaviour (outputs, runtime, side effects). So while yes, this is allowed, it's a really bad idea and will likely be very unpopular. Dec 25 '16 at 23:23
• @MartinEnder Bad example, but I think you got the idea. Dec 25 '16 at 23:27
• @devRicher I'm not sure how the example makes a difference. You're asking about challenges with an obvious shortcut that ignores the actual definition of the challenge. Either you allow that and the challenge gets boring or you disallow it and the challenge becomes badly specified. Dec 25 '16 at 23:29
• I think that people should not make others calculate things for no reason in golf challenges. Jan 22 '17 at 12:25

# Avoid this as much as possible

It's OK in the sense that it doesn't break any rules. However it's very lazy and doesn't make a good challenge. In general if you don't want hard coding and it's possible to hard code your output (or even inputs) then your challenge has some serious issues.

You should try to either

• Change your challenge so that hard coding is not feasible or competetive. For example, printing every prime under 10 is waaaay too easy to hard code, but printing every prime under 2 million is not.

• Or make it impossible to hard code the output/input. For example, a challenge like

Given a and b, print every prime number less that b such that n-a is a also prime.

Could not be hardcoded. (Both of these challenges are hypothetical. Either one could be considered a duplicate)

• Technically, its possible to hardcode every possible input (unless you are passed a list, or you accept an integer of any size) Jan 16 '17 at 20:31
• @NathanMerrill Yes, but if a challenge hardcoded the list of all primes that fit into a 32-bit integer, I'm sure that would get deleted as Not a serious contender Jan 16 '17 at 21:35

Although there is no explicit rule against using a "no hardcoding" rule to "fix" a fixed output challenge,

# A challenge must have objective validity criteria.

This means that "hardcoding" cannot form part of the specification wording unless the meaning of "hardcoding" can also be objectively defined. Unless we have a separate Meta discussion to agree on a default meaning for the word, this means that the challenge specification itself must contain a definition.

Although it may seem perfectly obvious what the word means, different people may draw the line through the grey areas in different places, particularly when it affects which approaches are valid in competition.

# These challenges should be disallowed

(Similar to the other answer here, but stronger.)

The only way to make this sort of challenge interesting is to make them a "do X without Y" style of challenge, but I don't see how it's possible to define Y in an objective way. In general, they should be modified to take a parameter to the algorithm in such a way that hardcoding the output becomes impossible.

Exception: If the requested output is fairly long and likely to be compressible in an interesting way, the challenge is possibly workable as a (in which hardcoding is "disallowed" via ensuring that a non-hardcoded answer will be shorter and thus get a better score).

• I'm not in favor of "disallow with exceptions" as a general principle. I think a general guideline, with case-by-case closing, is better. Dec 26 '16 at 9:27