This answer made me realise we should standardise on how to distinguish literal tabs in code from space characters. This becomes crucial in optimising the length of Python code, where 1xtab and 1xspace are different indentation levels.
3 Answers
Other than indentation issue, I am having problem with tab getting converted to 3 spaces in markdown editor, and code become broken.
here is my post if someone think, that's not the issue.
I think tab character shouldn't do force converting to 3 spaces for this site.
I think if your score depends on things that don’t represent properly on the website, you should post your solution in some way that allows to reliably reproduce the original file. Base64 encoding is a popular method of doing this.
Of course, any answer that provides a base64-encoded solution should also provide a human-readable solution (which may be longer than the “real” entry). I think my Koch snowflake answer, which uses all sorts of characters that are unprintable but nonetheless accepted by the Perl interpreter, exemplifies this.
So for Python code, you could write something like this:
for x in blahblah
for y in blahblah
<tab>some statement
but personally I would argue that this should not be necessary; just provide the code in “standard” readable indentation, and the “adventurous” one as base64.
I think this happens for Python submissions only (maybe Haskell?) Moreover, select few: only the ones that need to define multiple levels of code scoping.
I also suppose there exists a canonical optimal encoding that's the same for any snippet.
With this in mind, I'd say to give the answers in golfed spaces-only form, and count characters with the tabbed version, linking to here as for why.
<tab>
, which line is more indented? \$\endgroup\$