Simple question: if I answer a code golf with a function (for a task which is supposed to terminate), does the function actually have to be reusable? Or could it, say, modify some globals which break the function when called again?

(Note that this is not about whether functions may modify their inputs. I'm assuming that for each subsequent use the function is called with fresh copies of their arguments.)


3 Answers 3


Yes, functions have to be reusable arbitrarily often

That's the point of functions in the first place. If you want to break your environment, answer with a full program.

By "reusable" I mean that the function still complies with all the rules of the spec after it's already been used. It doesn't necessarily have to behave identically if the spec gives some leeway in certain points.

  • \$\begingroup\$ +1 from me. This is in line with the reasoning for disallowing breaking errors in functions in this accepted consenus. \$\endgroup\$ Commented Mar 25, 2015 at 10:42
  • 1
    \$\begingroup\$ Does this imply that global variables that are modified within the function and are not reset at the end/beginning are against the rules? If so, I (and presumably many C golfers) have a lot of newly invalid answers. \$\endgroup\$
    – BrainSteel
    Commented Apr 6, 2015 at 19:03
  • \$\begingroup\$ @BrainSteel Well if the function requires those global variables to be reset to work, then yes, that would be against these rules. In fact, this doesn't just imply it, this is the main purpose of this question/answer. However, there is no such thing as "newly invalid". Obviously, we won't apply a consensus like this retroactively. \$\endgroup\$ Commented Apr 6, 2015 at 23:25

No, functions may break after use

As long as the function completes successfully once, that's fine, just like with programs.

  • \$\begingroup\$ -1 from me. (can't vote) \$\endgroup\$ Commented Mar 25, 2015 at 10:44

Yes, functions have to be reusable arbitrarily often and behave exactly identically

This is essentially the same as this answer but it requires that subsequent calls of the function are 100% indistinguishable, even if the spec leaves some leeway in behaviour.

(Note that in the case of random challenges, the randomness and its distribution are part of the behaviour.)

  • \$\begingroup\$ -1 from me. This seems unnecessarily strict. I think complying with the spec should be all that's required, and might leave some rather clever golfing tricks. \$\endgroup\$ Commented Mar 25, 2015 at 10:56
  • 4
    \$\begingroup\$ This clashes with challenges that require random outputs. \$\endgroup\$
    – xnor
    Commented Mar 25, 2015 at 11:06
  • \$\begingroup\$ @xnor I would consider the randomness part of the behaviour. \$\endgroup\$ Commented Mar 25, 2015 at 11:19
  • 1
    \$\begingroup\$ So would this be a restriction against self-modifying functions? \$\endgroup\$
    – mbomb007
    Commented Jul 16, 2015 at 14:22

You must log in to answer this question.

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