82
\$\begingroup\$

If there is something that you find annoying / counterproductive / unfair / detrimental / no longer funny in challenges (question posts), describe it in an answer here, and propose a recommended response. Voting will indicate whether that response has the backing of the community.

For example, you might suggest one of the following:

  1. Comment linking here
  2. Edit question
  3. Close question
  4. Delete question
  5. Other (please specify)

Consider quoting from (rather than linking to) example challenges, as the fact that you are posting here makes it likely that the challenge may be edited making the link confusing for future readers.


For aspects of solutions (answer posts) to be avoided, see instead Loopholes that are forbidden by default

\$\endgroup\$
  • 1
    \$\begingroup\$ I think that this question is directly targeting the "rationales for short code lengths" posing as a broader (but mostly useless) question. I'd prefer if a different meta post were made specifically talking about the rationales, and allow the community to present both sides. \$\endgroup\$ – Nathan Merrill Jan 11 '16 at 14:41
  • 1
    \$\begingroup\$ @NathanMerrill You're welcome to post a response here. Just give your reasoning and recommend no action. It should work just fine on this post. \$\endgroup\$ – Alex A. Jan 11 '16 at 18:32
  • \$\begingroup\$ This may be a good thing to feature, or put in some other high traffic location so it can be treated as a reference. \$\endgroup\$ – J Atkin Jan 17 '16 at 1:39

38 Answers 38

17
\$\begingroup\$

Excessively long back stories

This is a site for people who like programming challenges. They already want to see your idea for a challenge. You don't need a back story to make your challenge appeal to them. If you decide to include some context for the task, try to keep it short.

Personally, I'm more likely to be put off by a needlessly long challenge wording. If it's long because it's complex, I'll read it. If it's long because of telling a story to make a simple challenge more interesting, it actually becomes less interesting to me. Simple challenges are good. Let's keep them simple.

\$\endgroup\$
15
\$\begingroup\$

Adding special cases for the sake of completeness

This is a generalization of "complicated" number types, and is similar in scope to adding unnecessary fluff.

What I mean by this is that many challenges will try to make the problem well-defined for all possible inputs, when the challenge would have been much better if the set of inputs had been constrained more.

The challenge that prompted me to write this was multiply a string and a number. The basic idea is to repeat each character in a string a given amount of times. However, it also specifies what to do when the input number is negative, and the behavior is not a simple extension of the behavior for nonnegative inputs.

In my opinion, this special condition makes the challenge worse. I come to PPCG to solve interesting programming problems, and conditionally reversing a string based on whether a number is negative is not an interesting programming problem. It is unnecessary boilerplate that stops me from wanting to solve the challenge.

Furthermore, there are languages in which solving the problem is hard enough as it is. In the challenge linked above, one user decided to try and solve the problem in Retina. Retina was not designed for numeric handling, and the solution only worked for positive inputs. Thus, the edge condition stopped the answer from being competitive.

There are also languages such as Underload where input scope would be complete. In Underload, the most natural representation of numbers is whole numbers, and requiring that negative numbers be handled makes the challenge feel much more clunky.

In general, always choose the smallest set of inputs for which the problem is well-defined and interesting, and only require submissions to handle those. Anything else is edge cases, and handling edge cases is not fun.

\$\endgroup\$
  • 7
    \$\begingroup\$ I'm with you except for your choice of example. Answers can handle both the forward and reversed cases together (1, 2 3) in clever ways for brevity,, and a challenge just to "copy each character n times" would have been nearly trivial. \$\endgroup\$ – xnor Jul 13 '17 at 7:57
  • \$\begingroup\$ @xnor I think it all comes down to target language. In this case the edge-case behavior does allow for some interesting solutions in certain languages. In the context of the languages I frequently golf in, however, it's nothing but boilerplate. \$\endgroup\$ – Esolanging Fruit Jul 13 '17 at 8:26
  • 2
    \$\begingroup\$ @xnor The problem, then, is that either the existing challenge or the simplified alternative would be closed as a dupe of the other, which means that there isn't a good way to balance having less but more clever solutions and having many solutions in more restricted languages. The only way I see for the second option to be preferred is if PPCG changed its voting habits and stopped upvoting more trivial challenges, something which has been brought up before but is beyond the scope of this discussion. \$\endgroup\$ – Esolanging Fruit Jul 13 '17 at 8:27
  • \$\begingroup\$ @xnor TL;DR You're right. \$\endgroup\$ – Esolanging Fruit Jul 13 '17 at 8:37
12
\$\begingroup\$

Exceptional edge cases

Don't require special behavior when the input is the empty list, the number 0, a negative length, etc. This makes for nasty surprises for solvers who worked on a solution only to find it's invalid on a technicality.

When possible, the edge case should follow the same rules as any other input without special instructions. However, even when the right answer is mathematically clear, it's often better to just specify the input will be non-empty, positive, etc, and avoid the issue altogether. If you do insist on including the edge case, do include a test case for it.

One place this comes up is the string representation of 0, which is conventionally '0' but mathematically is the empty string. Once in a while I find a nice recursive function that beats the boring built-in string conversion, but it fails the 0 test case, and it costs too many ugly bytes to patch. Specifying nonzero input would avoid this.

\$\endgroup\$
11
\$\begingroup\$

Requiring multiple types as return value

This is very similar to Explicitly disallowing or disadvantaging arbitrary (classes of) languages though it's more subtle (and not necessarily explicit):

A lot of languages don't allow returning multiple types therefore it's not a good idea to require different types as a return value because it rules out those languages for no reason (of course there might be challenges exempt from this).

Note: While not requiring a different type, the same should hold for exit codes and errors - in some languages it is not possible to generate errors or certain exit codes.

Examples

  • Given some input X if it satisfies property Y return a list of integers, else return a falsy value
  • Given some input X, if it satisfies property Y return the integers f(X), else return a string saying zzz
  • Given the input X if it achieves Y return some Z else exit with a non-zero error cod
  • Given X if it Ys then return some Z else error
\$\endgroup\$
  • \$\begingroup\$ One suggestion to fix this is to allow option types instead. Most languages have some sort of option type. \$\endgroup\$ – Wheat Wizard Oct 31 '18 at 20:09
  • 1
    \$\begingroup\$ @PostLeftGhostHunter: Yes that could solve it for a lot of "non-recreative languages" but that should be explicitly mentioned (I wouldn't call an Either Bool [Int] or Optional<Integer> truthy or falsy) and could still create problems for some esolangs. \$\endgroup\$ – ბიმო Oct 31 '18 at 20:14
  • 1
    \$\begingroup\$ I've long been uncomfortable with the arbitrariness of requiring "truthy or falsy". I prefer a requirement for two distinct consistent outputs. I can't see that a more specific requirement adds anything to most challenges. \$\endgroup\$ – trichoplax Oct 31 '18 at 21:41
  • \$\begingroup\$ @trichoplax: That would for example elegantly solve problems like example 1, but two distinct values is more specific than truthy/falsy. \$\endgroup\$ – ბიმო Oct 31 '18 at 22:13
  • 5
    \$\begingroup\$ The problem is that sometimes there isn't an example of a falsey value for that return type. Perhaps in these cases it might be better to let users assume that the input will always be valid \$\endgroup\$ – Jo King Nov 1 '18 at 14:16
  • \$\begingroup\$ @JoKing They can use (equivalent of) C++ optional type (or a pair<bool,T>) (although it depends on whether doing both input verification and computing the output at once is interesting) \$\endgroup\$ – user202729 Dec 10 '18 at 13:45
10
\$\begingroup\$

Assuming you've addressed sandbox feedback

When your challenge is in the sandbox and someone suggests a change or clarification, make sure your edit actually addresses their point. Too often the same complaints are brought up on the live challenge, and the poster is confused thinking they already dealt with them.

First, consider if the comment still holds true for your edited version. Maybe the rule is clearer than before, but still unclear. Maybe you've addressed some points but not others.

After editing, leave the challenge in the sandbox for more feedback. Maybe the change introduced new problems. Maybe the commenter will clarify their suggestions or offer further revisions. You can ping them in the comments to ask them to take another look.

\$\endgroup\$
8
\$\begingroup\$

Exclamation marks in titles!

Quite a lot of questions have exclamation marks at the end of their titles! To me this just seems like a vain attempt to attract more attention with the hope of getting more upvotes! I don't think I've ever seen a challenge with an exclamation mark in the title where the exclamation mark enhances the challenge in any way!

\$\endgroup\$
  • 20
    \$\begingroup\$ This is the only challenge I could see it being appropriate for. \$\endgroup\$ – Mego Jan 13 '16 at 3:57
  • 1
    \$\begingroup\$ @Mego Ha! yes!! \$\endgroup\$ – Digital Trauma Jan 13 '16 at 4:48
  • 7
    \$\begingroup\$ The only exception I could think of are titles which happen to be quotes that include the exclamation mark in the original source. \$\endgroup\$ – Martin Ender Jan 13 '16 at 18:34
  • 2
    \$\begingroup\$ youtube.com/watch?v=wyRLFWF2v_U \$\endgroup\$ – Robert Fraser Jan 14 '16 at 0:30
  • \$\begingroup\$ -1 And so does any non-straightforward title. \$\endgroup\$ – Akangka Jan 16 '16 at 13:52
  • \$\begingroup\$ It means the bad challenge title is for example : "Monday Mini-Golf #6: Meeesesessess upp teeexexextext" But the good challenge title is : "Do the webtollkit messing tranform in shortest code possible." \$\endgroup\$ – Akangka Jan 16 '16 at 14:01
  • 3
    \$\begingroup\$ @Christian actually, no. I'm only attempting to address exclamation marks here as IMO they are in their own category of pointless. I am not trying to address other styles of title - interesting, creative, boring or otherwise \$\endgroup\$ – Digital Trauma Jan 16 '16 at 17:53
  • 14
    \$\begingroup\$ If the title is an imperative sentence (Make a slow error quine maker!) or an exclamation (My god, it's full of spaces!), I fail to see the problem. \$\endgroup\$ – Dennis Jan 19 '16 at 17:15
  • 4
    \$\begingroup\$ @Dennis To me, imperative sentence with exclamation mark implies forceful command. Perhaps we're different at PPCG, but in my experience forceful commands don't go over that well in questions on other .SE sites. Fair point about your second example though. \$\endgroup\$ – Digital Trauma Jan 19 '16 at 17:26
  • 3
    \$\begingroup\$ The only time I've done this are to get around the 15 char limit for titles and I don't see how it really causes any harm to the actual challenge. \$\endgroup\$ – Downgoat Jan 20 '16 at 2:52
4
\$\begingroup\$

Pure programming puzzles

Despite our name, programming puzzles aren't generally welcome here. I'm talking about challenges where you're given a task with some impossible-seeming restrictions and must use some clever trick or language feature to solve it.

Programming puzzles are closed most of ther time for not having an objective winning criterion: something that lets you compare submissions to decide a winner. A criterion for a valid solution is not enough -- others need to be able to do better and beat the solution. You could say the first valid solution wins, but some people find it unsatisfying that someone else can win before they even see the challenge. It's better when more people can participate in and enjoy a challenge.

If it makes sense for your challenge, you can say the shortest solution wins (code golf) or have some other metric. This is best for puzzles that can be solved by more than one method, so the search for better methods can be interesting. Beware that once someone posts a solution to the puzzle, others can see it and copy the key idea with a better-scoring implementation.

\$\endgroup\$
  • 2
    \$\begingroup\$ As a sidenote, I don't think programming puzzles should necessarily be off-topic. It seems that whether pure programming puzzles are on-topic is still up for debate, but the reality seems to be that such questions get closed, so it's kinder to well-intentioned newbies to warn against posting them. \$\endgroup\$ – xnor Sep 13 '16 at 7:30
  • \$\begingroup\$ For those not familiar with the history: Is the name of the community correct? showed strong community support that "Puzzles" in the site name should be changed, so we would be "Programming Contests & Code Golf", which would allow all types of competitive contests, and avoid puzzles without a winning criterion. \$\endgroup\$ – trichoplax Sep 13 '16 at 12:59
  • \$\begingroup\$ The more recent discussion Should we change our name showed more support for keeping the current name, but there are lots of different issues mixed up in choosing a name, so I'm glad this answer now provides a place for voting on whether programming puzzles without a winning criterion should be avoided. \$\endgroup\$ – trichoplax Sep 13 '16 at 13:03
  • 1
    \$\begingroup\$ To reduce the problem of instant voting without reading the full content, would it be useful to change the title to "Programming puzzles without a winning criterion" or "Programming puzzles without a scoring method"? \$\endgroup\$ – trichoplax Sep 13 '16 at 13:05
  • \$\begingroup\$ @trichoplax Good idea, I changed it to "Pure programming puzzles". \$\endgroup\$ – xnor Sep 13 '16 at 17:03
  • \$\begingroup\$ From codegolf.stackexchange.com/help/on-topic : "Non-challenge questions that are related to solving programming puzzles or a particular type of challenge are also on topic." \$\endgroup\$ – gaazkam Oct 29 '17 at 0:01
-9
\$\begingroup\$

Entirely nonsensical rationales for short code length.

This was fun (and was documented as a local meme) when the rationales vaguely made sense, for example, "We want the program that does this to be as small as possible so it can fit into the margins" (from The Margin is too Narrow).

However, this has gotten out of hand. Recently more challenges have included rationales that make absolutely no sense, in or out of context. For example, "Because you can only stack about 5 goats before they start to fall, your code will need to be as short as possible" (from Tokenize a Stack-Based language, since edited out).

In an effort to keep challenge specs concise and readable, I propose that we do the following when we see something clearly off-topic for the challenge in the spec:

  • Edit the question
  • Link here in the edit description (it will appear in the revision history)
  • Send attack drones
\$\endgroup\$
  • 44
    \$\begingroup\$ "Send attack drones" is an entirely nonsensical solution to these entirely nonsensical rationales. :P \$\endgroup\$ – ETHproductions Jan 10 '16 at 21:48
  • 2
    \$\begingroup\$ Just wondering, did Trichoplax post this question just so you could post this answer? Are you Trichoplax in disguise? \$\endgroup\$ – Level River St Jan 11 '16 at 1:57
  • 1
    \$\begingroup\$ Chemistry-tagged challenge: Because there are only 6.022140857×10^23 atoms in a mole, your co... (yawn) :-D \$\endgroup\$ – Level River St Jan 11 '16 at 2:00
  • \$\begingroup\$ @steveverrill Haha no, I think trichoplax would have posted this question anyway, though I think if I hadn't posted this answer, he would have. ;) \$\endgroup\$ – Alex A. Jan 11 '16 at 2:07
  • 3
    \$\begingroup\$ What counts as entirely nonsensical? I've used "However, I've gotten lazy in my old age. So I'm outsourcing it to you, and disguising it as a code golf challenge.", which I think could count as either nonsensical or perfectly reasonable, depending on whether you believe it or not. \$\endgroup\$ – Geobits Jan 11 '16 at 3:58
  • \$\begingroup\$ @Geobits That's not a rationale for short code length though. But I think people should use judgment as to whether something is entirely irrelevant to the spec and should be removed. \$\endgroup\$ – Alex A. Jan 11 '16 at 4:21
  • \$\begingroup\$ The only problem with individual judgement in this case is that something only has to annoy one person to result in an edit, even if no one else finds it annoying. There's something to be said for @NathanMerrill's suggestion in the comment on this meta question. \$\endgroup\$ – trichoplax Jan 11 '16 at 15:00
  • \$\begingroup\$ I suggest downvoting. This would be too subjective if people begin to look for workarounds. Having a dumb rule may make it seemed interesting looking for workarounds to some askers. \$\endgroup\$ – jimmy23013 Jan 11 '16 at 15:06
  • 28
    \$\begingroup\$ i don't care enough to vote but i will say that i'd feel kind of weird about a rule dictating what kind of jokes you're allowed to tell on this site \$\endgroup\$ – undergroundmonorail Jan 11 '16 at 15:33
  • 8
    \$\begingroup\$ I don't think this answer is a perfect fit for the question, because "no longer funny" implies that it was funny once... \$\endgroup\$ – Peter Taylor Jan 11 '16 at 16:09
  • \$\begingroup\$ @PeterTaylor this is a good point, and makes me realise I phrased the question poorly. I've edited to hopefully improve this. \$\endgroup\$ – trichoplax Jan 11 '16 at 18:20
  • \$\begingroup\$ What about the ones that make sense? Also most of them are at the bottom of the post, I'm not sure how that affects readability. \$\endgroup\$ – J Atkin Jan 15 '16 at 3:10
  • 31
    \$\begingroup\$ Wait, are you saying that just because you don't find the ridicuous jokes funny but I do, I'm not allowed to put them in my challenge rationale? pah \$\endgroup\$ – cat Jan 18 '16 at 7:40
  • 1
    \$\begingroup\$ @cat It's not because they aren't funny, it's because they clutter the specs. Short code rationales add nothing to challenges. \$\endgroup\$ – Mego Jan 26 '16 at 22:55
  • 6
    \$\begingroup\$ They add humor (subjectively), in much the same way that things like struck-through "instructions" for the puppy command do, for instance. I'd be hard pressed to say the puppy commands add less clutter, given that they're within the actual instructions and not as a fore/afterword. \$\endgroup\$ – Geobits Mar 24 '16 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .