5
\$\begingroup\$

I recently posted a Java golf that massively abuses for loop syntax to save a few characters. However, this makes it almost impossible to ungolf without changing the semantics (of the uncompiled code).

Should I do so?

Pros:

  • Ungolfed logic is easier to read/follow

Cons:

  • Some of the golfing tricks are no longer present in the ungolf

Followup: What about changing variable names? I've seen it done in some cases and not in others.

Thoughts?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Actively, I really only ungolf Mathematica answers. In that case, yes I do change variable names and structure as long as the actual algorithm isn't affected. That also means moving around and adding/removing temporaries and stuff. In any case, it's up to you - ungolfed versions are just for the readers to have a somewhat more pleasant time figuring out your approach; there's no need for hard and fast rules. \$\endgroup\$ – Martin Ender May 7 '14 at 22:07
  • 1
    \$\begingroup\$ @m.buettner I'm actually of the opinion that ungolfed code should correspond identically to golfed code, but with idiomatic indentation and sane identifier (variable, function, class, module, etc.) names. \$\endgroup\$ – Chris Jester-Young May 7 '14 at 22:14
  • \$\begingroup\$ @ChrisJester-Young I think I could be convinced to follow the same style in the future. I think for me it would depend on whether the challenge is more algorithm or golfing centric. If coming up with a good algorithm is an important part of the challenge, I think a clean version that expresses the algorithm more clearly can be very helpful. But I just read Geobits's answer, and I agree that adding an explanation instead could be just as (if not more) valid. \$\endgroup\$ – Martin Ender May 7 '14 at 22:27
  • \$\begingroup\$ There are some cases where the "ungolfed" version just has to have the same atrocity as the golfed version. Just comment about it, either in the code or in the post. \$\endgroup\$ – dmckee --- ex-moderator kitten May 7 '14 at 23:13
2
\$\begingroup\$

Golfed code is, primarily, about making the shortest code possible. It is not necessary to optimise for "readability/followability". This means that the ungolfed version may equally be unreadable. That's okay.

By way of example, in my Scheme RPN calculator solution, I used `(,foo,@bar) as a golfed version of (cons foo bar). My ungolfed code also used that notation (with a space in the correct place, of course), and I added a note saying that it's equivalent to cons. That way, people who want to follow the code can, but the ungolfed version is still one-to-one with the golfed version.

Variable names should all be as short as possible in golfed code. Usually, this means they should be single-character names. Thus, it's okay to change those to more readable names in the ungolfed version.

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

Normally I don't call mine an "ungolfed" version to start with. I say "here it is with line breaks" just to avoid this sort of thing. If my code isn't legible like that, then it needs a short explanation, not variable names and braces.

Especially with Java, the golfed code is sometimes still a large amount of characters on a single line. That sucks mainly because scrolling horizontally is just horrible. With a few line breaks, it makes it much easier to follow, even without unrolling the loops, adding braces, changing variable names, etc.

If you have a particularly abusive loop (I assume you mean a bunch of statements crammed into the last section), you can just add a line break for each statement:

for(int i=0;i<whatever;
                       k/=i,
                       m/=i,
                       System.out.print(i++)
                       );

It's not the prettiest, and I only recommend that if it really looks bad on one line (adding horizontal scroll, for instance).

Besides just line breaks, it should also be indented properly. I don't care what conventions you follow, as long as it's consistent and obvious what block goes where. The braces in particular become basically obsolete at that point, and anyone who's seen a few golfed answers should be able to see the structure immediately.

This also has the advantage of making it immensely easier to get an "ungolfed" version that corresponds exactly to the golfed one. All you have to do is edit in/out a few line breaks. There are online minifiers that can take care of that for you for several languages, and options in some IDEs to add them back in. That's particularly useful if you have golfed 2-3 characters out several times. Going back through and changing variable names in both versions you posted and making sure they're both "right" takes a bit more.

\$\endgroup\$

You must log in to answer this question.

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