7
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Btw, how much indentation does one tab count for in python? I mean, if I have ` six spaces` and <tab>, which line is more indented? \$\endgroup\$ – R. Martinho Fernandes Jan 28 '11 at 3:38
  • \$\begingroup\$ A <tab> is equivalent to 8 spaces when indenting in Python. So nested for loops can use a single space to indent the outer loop and tab for the inner loop. \$\endgroup\$ – gnibbler Jan 28 '11 at 10:08
  • 1
    \$\begingroup\$ 1 tab = 1 byte, there isn't much to discuss here \$\endgroup\$ – user11 Jan 28 '11 at 16:23
  • \$\begingroup\$ @M28 I think you misunderstood the question. Note that markup converts tab characters into 4 space characters. \$\endgroup\$ – marcog Jan 28 '11 at 16:27
  • \$\begingroup\$ Yep, I read too fast \$\endgroup\$ – user11 Jan 28 '11 at 16:29
  • \$\begingroup\$ Another language which has trouble with markdown's white-space behavior is column-formatted fortran. Just try to get a markdown code block that actually has continuations at column six and cone starting at seven. I dare you. Not that this is a big problem for code-golf, but fortran might be able to do some interesting things for non-golfing challenges. I may use html blocks in the future, but I don't know how to get syntax coloring with them. \$\endgroup\$ – dmckee Feb 5 '11 at 14:57
  • \$\begingroup\$ @gnibbler actually its 4 spaces \$\endgroup\$ – caird coinheringaahing May 28 '17 at 13:14
4
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

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