# Can serious contenders do more than the challenge asks for?

As our help center likes to put it:

All solutions to challenges should:

• Correctly implement the required specification.
• Be a serious contender for the winning criteria in use. For example, an entry to a code golf contest needs to be golfed, and an entry to a speed contest should make some attempt to be fast.

Per our policy about answers not meeting the challenge specification, non-serious contenders are subject to deletion.

In Clarifying "serious contender" in the help center, we tried to clarify what serious contender actually means. @Mego's answer – currently the highest scoring one – starts as follows.

A serious contender is a submission which makes a serious effort towards optimizing the submission's score within the chosen language(s) and other choices (such as algorithm choice or optional restrictions/bonuses taken).

That covers different algorithms (think brute force vs closed form, each of which might have a shorter implementation in a given language), bonuses (now frowned upon anyway).

Restrictions are trickier. Self-imposed restrictions like a clean exit or avoiding warnings seem to be accepted in general, but a new one – input validation – has come up in the last couple of days. Specifically, I'm talking about these answers:

Both challenges imply or even explicitly state that the input will be "valid" (i.e., obey a certain format), yet the author decided to validate the input in his answers because he considers code without input validation incomplete. While that may very well be true for production code, the challenge specifications say otherwise.

That begs the question: What kind of self-imposed restrictions should be allowed for a serious contender in code golf competitions, even when adhering to them inevitably elevates the byte count?

Realistically, I don't expect a clear-cut division as a result of this meta discussion, but coming up with a few necessary or sufficient conditions (or at least partial white- and a blacklists) that cover most cases should be possible.

# Serious contenders do not contain superfluous code

I propose the following:

If a part or multiple parts of the code can be deleted without affecting its functionality with regard to the challenge specification, the submission is not a serious contender. Answers that meet this criterion should be amended. Answers that meet this criterion deliberately or completely should be removed.

I don't mean a few unnecessary bytes here and there. We all miss a golfing opportunity every now and then, and a new user will naturally miss more golfing opportunities than an experienced one.
In this case, the proper course of action is guidance, not threatening deletion.

This covers all illustration in @Mego's answer that concern code golf and more. A few examples:

• Variable names should be as short as possible.
• Non-essential whitespace should be removed.
• Brackets should be removed whenever possible.
• Comments should be removed, unless they are required to comply with the challenge's rules.
• Program shouldn't perform input validation, unless the challenges requires this.
• Programs shouldn't display input prompts (e.g., Please enter an integer:), unless the challenges requires this.

While this doesn't even attempt to cover all forms of non-serious contenders, an answer that can be golfed down by merely removing a part of the code is a clear indication of a non-serious contender.

Note that the following answers, although strictly speaking not as short as possible, cannot be golfed by simply removing a part of the code, meaning that my proposal does not make them non-serious contenders.

• Answers may choose any programming language, including intentionally verbose languages.

• An answer may implement any algorithm, even if golfier ones exist.

Even if a brute force solution leads to the shortest code, seeing efficient algorithms (if properly golfed) is still interesting.

• Answers may choose not to take advantage of some "ugly hacks", such as terminating the program by crashing the interpreter.

This should be a personal choice, not be forced upon all competitors.

• Re: input prompts - what if they come from the language/input method, and are unable to be suppressed? I think they should be allowed in that case, but this answer seems to disallow that.
– user45941
Dec 8 '16 at 7:48
• I really don't like how you've worded this. Superfluous could be considered to cover everything. I disagree that input prompts/validation are a bad thing, as those are self-imposed restrictions on program functionality, not just a missed golfing opportunity. Furthermore, I could add some "superfluous" memoization because I want my algorithm to be n^2, not 2^n. Or the "superfluous" polyglot (that everybody seemed to love, but deleted). Dec 8 '16 at 13:59
• The key here is that the user is still showing effort to golfing. That's always been our rule of thumb. Simply because they like to make the challenge more difficult doesn't mean they aren't aiming to golf. Dec 8 '16 at 14:00
• @NathanMerrill If by "make the challenge more difficult", you mean "solve a different challenge", then yes, that's superfluous. They're not simply trying to golf the actual challenge. Dec 8 '16 at 14:13
• @Mego Input prompts are merely an example; the proposed policy is the quoted part below the header. If they are part of the language, there is no part [...] of the code [that] can be deleted without affecting its functionality. Dec 8 '16 at 16:04
• I agree with this, with one exception: some users (mainly new users) may not be familiar enough with their language to know what code is superfluous, and in this case they should simply be encouraged to remove the extra code. Obviously this particular user knows better and is simply not willing to give up their extra code. Dec 8 '16 at 16:05
• @ETHproductions I agree, which is why I included the footnote. Elaborating: I'm not talking about missed golfing opportunities. A new user will naturally miss more golfing opportunities than an experienced one, and the proper course of action is guidance rather than threatening deletion. Dec 8 '16 at 16:13
• @Geobits They are golfing a more difficult version of the actual challenge. I honestly see no problem with that, and if we restrict it, then suddenly we are starting to miss out on some really clever answers. We have a tradeoff here: Either we increase the amount of cleverness/fun of this site, or we increase the "purity" of the site. Do you really prefer the latter? Dec 8 '16 at 16:27
• @NathanMerrill It doesn't take "cleverness" to add a bunch of extra tasks to a challenge and solve that. Yes, in some cases the answers may be clever, but it opens the door for a whole lot of unclever things. [code-trolling] was all about adding extra things to the code actually needed, and it was arguably fun. Dec 8 '16 at 16:31
• I agree, but that isn't what's happening. You're preferring the "what-ifs" over the what's actually happening. Dec 8 '16 at 16:32
• No, you just disagree that it's happening. The post that kicked this off was (imo) exactly the showoffy type of thing designed to attract "cool" votes that I don't want to see, clever or not. Dec 8 '16 at 16:33
• @NathanMerrill Making the challenge more difficult and adding arbitrary things the challenge didn't ask for are apples and oranges. Also, when I write a function that could heavily benefit from memoization or just some additional short-circuiting, I usually include a remark that the code could be sped up significantly for X extra bytes as follows. That way, you have a competitive entry and a usable one. Dec 8 '16 at 16:41
• @Dennis how would you make a challenge more difficult without adding arbitrary things? Dec 8 '16 at 16:48
• @xnor I agree completely with Mego's answer. An answer that uses a different algorithm cannot be golfed down by simply removing a part of it, so it can still be considered a serious contender if it implements that algorithm in a concise manner. I'll add a few counter-examples to my post to clarify. Dec 8 '16 at 18:00
• There is a big difference... You believe programming as one countable tool, something one can close in the box of your failing laws; I believe programming is art, where the authors see what is better, what is right and what is wrong, what is beautiful, what can run ok etc
– user58988
Dec 11 '16 at 9:31

# Adding difficulty to the challenge is allowed

A primary purpose of this site is to promote clever answers. This cleverness has always been focused on optimizing one's score.

I'm proposing that we allow people to place additional self-imposed restrictions, while still optimizing their score.

Some examples would be:

1. You want to do a particular challenge without using a particular feature of your language (Solving an equation without using eval).
2. You want your submission to be a polyglot that performs the task in 3 different languages
3. A challenge indicates that a submission needs to solve inputs from 1 to 10 in under a second. You want to handle any input from 1 to 1000.

In each of these cases, the submission would still need to show effort in golfing, as that is still the scoring criterion.

1. Why not just make it a separate challenge?:
• This doesn't always work, especially if your restrictions are based on the language you are writing it in
2. They aren't competing in the same challenge anymore.
• I agree. However, we've already indicated that different languages aren't competing against each other. This isn't that different to picking a different language without a particular feature you don't like (Looking at you Geobits)
3. This could lead to submissions that add arbitrary restrictions and aren't really clever/interesting.
• I agree. However, I don't think that this has been an issue historically, and I don't think it will become one. If it does become a problem, we can revisit the topic to fix the issue. For now, a simple solution is to downvote uninteresting submissions.

The TL;DR is:

1. We like clever answers, and therefore
2. We should allow people to add self-imposed difficulty the challenge to increase the possibility for clever answers
• 1. For the most part, this isn't incompatible with my proposed criterion. Solving an equation without eval results in a completely separate answer. In general, so does making an efficient submission (in cases where making the submission efficient is just a trivial modification, the shorter alternative should be the submission, and the modification can be included as a remark). 2. Polyglots open a whole different can of worms. They'll probably be popular and get a lot of upvotes, leading to more polyglots. Dec 8 '16 at 17:44
• Just because something is popular doesn't mean it's good though (remember code trolling?). Having lots of polyglots to non-polyglot challenges isn't a good thing in my opinion. Yes, we should encourage cleverness, but in code golf competitions, that means finding clever ways to reduce your byte count, not to make it higher. PPCG is a coding competition site, not a blog. 3. If it does become a problem, we can revisit the topic to fix the issue. It has already started (exhibit A, exhibit B), which is why I started the discussion. Dec 8 '16 at 17:44
• User RosLuP has an agenda (answers without proper input validation are incomplete), and tries to push it via answers to code golf challenges. That doesn't make the challenge more difficult; it just adds some boring overhead to answers for something most challenges rule explicitly or implicitly as unnecessary. As long as there are only two answers of this kind, downvoting may be enough, but they seem unbothered by the downvotes and uninclined to stop. Dec 8 '16 at 17:44
• 1. I don't see how this is compatible. I could say "this chunk of code is all superfluous, you simply need to replace it with an eval". Sometimes the modification for efficiency is trivial, sometimes its not. I'd be ok with allowing the efficient version be posted as a standalone answer. 2. I disagree, but this is basically a matter of opinion. 3. Those links don't work. RosLuP has had several agendas and I don't think preventing so many good answers to stop one of their agendas is a good idea. Dec 8 '16 at 17:51
• 1. You keep getting hung up on the word superfluous. The policy I propose is more than just the header of the post. 3. I've modified the links shortly after posting the comment; you might have to refresh the page to get the working ones. Agendas have no place in code golf submissions, period. We have a meta site to discuss policies. Dec 8 '16 at 18:03
• On the "boring overhead" of my functions that would have to check for input errors are functional to my "agenda": for to consider complete one function, it has to check their input, in fact, I doubt one function out here that don't check its input could be considered ok and complete
– user58988
Dec 9 '16 at 19:05
• Suggestion: allow self-imposed difficulty as long as answer also includes solution without self-imposed difficulty. Jul 8 '19 at 17:34

# Answers should be a genuine attempt at the challenge

If an answer is well-golfed, but contains code that can be removed, then it is still an answer, but is not as good as it could be. The correct response is a comment to point out the opportunity for further improvement. It's possible that the contestant missed some crucial wording in the question. Sometimes, even, questions are edited with new constraints while the contest in in progress (I know - shocking news).

Answers should be free to include such checking as an item of (non-scoring) additional information. Many of us like to include a neater, non-golfed version of our code, particularly when the algorithm is the interesting part, but it's obscured by the golfing. If you want to show off your production-code skills, that's the right place to put it.

Voting to close should be reserved for responses that make no attempt at competing - in code golf, that usually means neatly-formatted code with multi-character identifiers - the kind of thing you'd expect in an answer on Stack Overflow.

• There's no such thing as voting to close an answer. There are downvotes and votes to delete. Dec 16 '16 at 13:23

As a devil advocate to dennis's post.

# Challenges may contain extraneous code

So long as the requirements to fulfill the challenge are completely met, all code should be accepted. In most cases, serious contenders won't put extra code into challenges similar to challenges. However, in a less competitive space, there may very well be the urge to go above and beyond in your answer. This sort of overachieving should be encouraged.

Why would we need extraneous code?

• Newbies almost always have code that is extraneous,but still fit the challenge. We cannot simply dismiss them as "non-serious" competitors. That's not a good attitude.
• It's not maintainable. Removing and/or fixing every answer (or to even attempt to) that has 'extra brackets' somewhere in it is a large task. It would put undue stress on our moderators and community.
• Naturally, most extra code is not competitive in most games. There is no need to impose a 'survival of the fittest' rule to remove the worst ones. The answers will sink naturally.
• We have down-votes for this reason. If an answer is clearly written by somebody looking for a reaction, give the answer a down-vote.
• This discussion is tagged code-golf and isn't meant to cover other types of challenges. Dec 8 '16 at 16:06
• @Dennis fixed.. Dec 8 '16 at 16:07
• "Naturally, most extra code is not competitive in most games. There is no need to impose a 'survival of the fittest' rule to remove the worst ones. The answers will sink naturally." Except that this doesn't always happen, and isn't even likely to in some cases. If the extra code is of the "look at this other cool thing I can do" variety, it's likely to get upvoted highly, outscoring serious contenders. This effect is magnified if the question is on the HNQ list, where many visitors will upvote it for "cool", yet may not even have the ability to downvote due to lack of rep. Dec 8 '16 at 16:18
• I've addressed points 1 and 2 in my answer. I'm not talking about missed golfing opportunities Dec 8 '16 at 16:27
• @Dennis that's fine. Dec 8 '16 at 16:29
• All this count 153 views and 8-9 votes up and down... What think these 153? Are they robot?
– user58988
Dec 9 '16 at 14:21
• If an answer is clearly written by somebody looking for a reaction, give the answer a down-vote. Interesting, seeing as this is a "devil's advocate" to Dennis'... Dec 13 '16 at 20:42
• @Flp.Tkc what's interesting? Denis's answer had 1 upvote at the time I posted this. I wanted to see where people were leaning. Dec 13 '16 at 20:45