Revision beadc872-0166-4494-b7b5-0113c4a28ee5 - Code Golf Meta Stack Exchange
My basic guideline would be "as the problem statement says". Which is mostly to mean it's allowed to explicitly override anything it wants from what I'm about to say next.
Actions to invoke
-----------------
For test-case/IO programs, I like it better when the whole invocation is possible as a single line, through redirection or bash herestrings (`<<<`).
$ interpreter script.ext < input_file
$ program <<< 'input line'
$ echo -n 'sensitive input' | ...
If for justifiable reasons input can't be redirected in (*e.g.* has to be terminal input, and the problem statement didn't forbid that—and I don't think it should), it should be with minimal hassle. Line by line would likely be too much for my personal level of acceptable laziness.
(kinda OT: I haven't tried the Eelvex example you linked to, but the data-pasting requirement seems more like an overhasty copy-paste from his live demo session than an actual requirement of his program)
Character count in interactive solutions
--
Only the characters part of the code are counted in. That includes newlines, if they're needed for the code to be well-formed. Unless overruled by problem statement, input is not counted in. That includes newlines part of the input. I trust the problem statements to be clear enough in this regard, and the answerers to be fast enough to request clarifications when needed.
Digressing from there, I don't think input data should be allowed to be mixed with code. Separate file, input stream, prepended, appended, both? (J again), stuck in parentheses for a function call, ok, but [this is too much][1].
Special invocations
--
This one is more subtle than the question makes it. I make a difference between:
- options to bring the language level to a specific point. This has mostly been observed with Perl 5.10+, but I feel it might pop up again with Haskell Prime. It was kept a bit more hidden for compiled languages anyway (C99, C++0x) The consensus up to now on SO and here was "the `-M5.010`, when needed, is free".
- options to request different behaviors from the interpreter. This is the n/p/l/a/f family of options in perl/sed/awk/ruby. I count those as a difference in character count to the shortest equivalent invocation without them. This can be a bit tricky at times<br>
`perl -nle 'stuff'` is 2 characters more than `perl -e 'stuff'`, so it counts for 2 more characters than the contents of `stuff`. **This supposes `stuff` needs no quoting to go in single quotes**, or it would need more characters to escape. If not, either the escape characters are counted in as well, or you put the script in a file, and count the difference to `perl -nl file.pl`, which now includes the hyphen.
- OT: the shebang follows the same rules (it's free, except for the behavior-modifying parts of it)
- external filtering: IMO this kicks the submission out of single language league, and it should be evaluated as a standalone bash (or other) script. That shoudln't prohibit it from using multiple script files, named with a single letter if the interpreter allows it; it makes the submission less readable anyway and that should be enough to discourage. We might want to devise a tolerance for a single interpreter name (`jconsole` seems a bit arbitrarily handicapped compared to `dc`).
Named functions?
--
If the problem statement asks for a statement, answer with a function. If the language allows/supports anonymous functions, use them at will. If not, well you don't really have a choice, do you?
For languages without functions... I don't know.
Compute this!
--
You didn't ask for it, but I'm mentioning it *en passant* as it's related. For problems that just ask "compute this" (usually with such and such constraints), I'm very tolerant on the I/O.
- The interpreter's interactive output is good to me.
- Requiring the code to be pasted in is ok, as long as it can be done in a single shot and the newline is counted in if needed.
- Requiring a bit of environment tweaking to prevent long answers from being truncated is ok and free.
- Environment tweaking that alters the calculations is **not ok**. (I'm thinking of bc's precision and base)
[1]: http://codegolf.stackexchange.com/questions/1294/anagram-code-golf/1306#1306