Can serious contenders do more than the challenge asks for?

Question

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:

• Axiom answer to “Binary to decimal converter”
• Axiom answer to “Subsequence Substitution”

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.

Answer 1

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.

Answer 2

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.

To address concerns:

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

Answer 3

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.

Answer 4

^{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 code-golf 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.