guidelines and recommended defaults

These rules apply unless otherwise stated (e.g., if a challenge stated “output may not have trailing newlines”). I use the terms must, must not, should, should not, may, etc. consistent with RFC 2119.

At the end of the day, do what you want with these problems, but this is my recommended golfing experience.

General guidelines

• A solution must either be must either be a full program, or a function.
  • A full program is a piece of code, usually a file, that can be provided to a programming language implementation wholesale. See full program guidance for more information.
  • A function is a snippet of code, usually surrounded by helper code to invoke it, that can be called with the appropriate arguments and produce or return the appropriate output. See function guidance for more information.
• Where problems require multiple, separate inputs, solutions may always receive them in a consistent order they choose.
• Solutions may reasonably ignore language and hardware limitations, such as memory and the recursion limit, so long as all listed test cases execute without issue.
• Solutions should complete under 60 seconds on normal hardware.
• Solutions must work for more than just a limited subset of possible inputs (e.g., they must work for more than just the provided test cases).

Full program guidance

• Input must be from STDIN or the screen unless otherwise stated. This includes (but is not limited to):
  • Reading from file descriptor 0 (STDIN).
  • Reading from /dev/tty.
  Importantly, solutions must not assume input is pre-loaded in a variable, memory, a file, etc.
• Output must be to STDOUT or the screen unless otherwise stated. This includes (but is not limited to):
  • Writing to file descriptor 1 (STDOUT).
  • Writing to /dev/tty (or equivalent).
  • Writing to a GUI element (e.g., document.body.textContent).
  • Writing to a GUI popup (e.g., alert). The popup should be somewhat persistent, e.g., avoid flashing a popup with output.
  Importantly, solutions must not simply calculate the result without displaying it in some way.
• Command line and/or interpreter flags may be used, but are discouraged because they are stinky and dumb (technical terms).
• When comparing solutions, I recommend that you consider a solution without flags, or with different or fewer flags, as not directly competing with other solutions, even if the base language is the same.

Function guidance

• Functions should take the appropriate input(s) (if any) through function parameters.
• Functions should use a return value to provide output.
• Functions may adhere to full program rules for input and/or output.

Category specific guidelines

string.i string.o string input and output

• Strings may be represented using any of the following:
  • An internal string type;
  • A list or array of characters or single-character strings; or,
  • A list or array of bytes in a reasonable encoding corresponding to the input/output.
• Where line breaks (except bytes which happen to be e.g. 0x0A) are I/O, solutions may consistently choose to use \n, \r, or \r\n, or instead provide output as a list of single-line strings.
• Output (not input) may have any number of leading and trailing newlines.
• Each line of output (not input) may have any number of (consistent) leading spaces (such that trimming a consistent number of spaces from the start of each line, which may differ, results in the requested output).
• Each line of output (not input) may have any amount of trailing spaces, even if not consistent, including where problems specify trailing whitespace (and do not specifically ask solutions to replicate it).

numeric.i numeric.o numeric input and output

• Where floating point numbers are I/O, results must be accurate to 5 decimal digits after the decimal point.
• Solutions may represent floating point numbers instead as fractions (either exactly accurate, or accurate to 5 decimal digits after the decimal point, as above.
• Solutions may represent fractions using any of the following:
  • An internal fraction type;
  • A dedicated struct with numerator and denominator members;
  • An ordered array, list, or tuple with numerator and denominator components; or,
  • A complex number with real and imaginary parts corresponding to numerator and denominator (in any consistent order).
• Where the output is limited to a single integer from 0 to 255, a solution may provide output via exit code.

boolean.i boolean.o boolean input and output

• Solutions may always substitute the concepts of true and false with the concepts of truthy and falsy. (E.g., truthy = value ? true : false;.)
• Solutions may always decide to consistently invert its output (i.e., give true for false and false for true).
• Solutions may provide boolean output via exit code (i.e., 0 for true and anything else for false, or vice versa).
• Similarly, solutions may terminate cleanly for true and terminate with an error for false (or vice versa).
• Solutions may terminate for true and never terminate for false (or vice versa).

sequence.o sequence output

• Solutions may always decide to implement a sequence as either:
  1. An (indefinite, if applicable) iterator (including (indefinite) STDOUT or screen output);
  2. Requiring an index as input (starting, consistently, at 0 or 1), and outputing the entry in the sequence at that index; or,
  3. Requiring an integer N and outputing the first N members of the sequence.