# New puzzle type: code-shuffleboard

Before I discovered that code golf was "a thing", I'd played against myself quite a bit. Often, I'd get down to 104 characters, say, and crank on it until I could get it to 100. But, if I can't get it below 90, I like to get it back to 100, 'cause it's nice and round. I deem this "code shuffleboard".

The idea behind code shuffleboard is to implement an algorithm in exactly a certain number of bytes. Of course, it's trivial to inflate a golfed solution by adding whitespace, using longer variable names, etc. So, the rules would be:

• No unnecessary whitespace
• All variable / function names (if applicable to your language) defined in the code must be 1 letter (unless you run out of letters, then you can use 2-letter variables)
• No useless code: deleting anything from the program must break it

In short, every character must contribute nontrivially to the functionality of the program.

Would other people participate in this? For a twist, one could require that the code fit inside of a certain sized rectangle, with no room to spare (though, that would risk favoring J/GS overly much).

• Sounds nice. I'll definitely use it for my next problem. – Alexandru Jul 6 '11 at 7:42
• "No useless code" sounds rather hard to define objectively. And what's your position on changing variable names to make whitespace necessary which wasn't necessary before? (I'm thinking of GS' weird parsing). – Peter Taylor Jul 6 '11 at 9:29
• My understanding is that 'no useless' == 'no dead code'. – Alexandru Jul 6 '11 at 12:30
• @Alexandru, that's one interpretation, but x=y/z+1-1 seems to me to contain some code which isn't dead but is completely useless. – Peter Taylor Jul 6 '11 at 16:05
• @Peter, I clarified the statement; does that help? I'm not familiar enough with GS to comment on changing variable names; can you provide an example? – boothby Jul 6 '11 at 23:30
• Ok, seems a lot harder to wiggle now. An example from GS would be storing something in a variable and then later retrieving it and subtracting 5. If the variable is $that's$5-, but if the variable is x it has to be x 5- to avoid the variable name being lexed as x5. – Peter Taylor Jul 7 '11 at 5:51
• Wow, what a screwy language. I think I'd accept that, since it would probably have numerous side effects. On the other hand, I realized that my rule doesn't forbid for(x=10000;x<100010;x++)print x-10000, though it probably should. – boothby Jul 8 '11 at 2:46
• The rectangle idea would be fun for Befunge and its derivatives, which are useless for normal golfing despite all the 1-char commands, because the 2D layout tends to use up a lot of bytes. – marinus Jul 9 '11 at 9:27
• On second thought, that example I provided would be forbidden; deleting every instance of 1000 would preserve functionality – boothby Jul 9 '11 at 19:09
• So basically the criterion is: »It shall be impossible to naïvely golf the code further – further shortening must involve rewriting or rearranging the code or other drastical measures«? – Joey Jul 10 '11 at 8:44
• Would the number of characters be given in the task? That'd probably be a horrible idea, given how far from each other golfed solutions often are and inflating something by a few dozen bytes just for the sake of it is probably hard. – Joey Jul 10 '11 at 8:46
• Joey's point is a good one. Perhaps it should be expressed as "must be a multiple of N chars" where N is e.g. 32. – Peter Taylor Jul 10 '11 at 20:12
• What about this? stackoverflow.com/questions/6430448/… Putting parens as fillers (a*a*a)*(a*a*a) and claiming removing them breaks the code because of floating point precision. – Ming-Tang Jul 11 '11 at 2:31
• @SHiNKiROU, if an author were to hack numerical instability into their solution for the purpose of requiring extra parens, I'd absolutely give it to them. That is precisely the spirit of code-shuffleboard. – boothby Jul 11 '11 at 7:54

I don't think it's such a good idea.

If I try to press the last byte out of my code, I often find a byte here and there, and another one later.

Collecting 3-4 techniques and reversing them would allow me to add some unnecessary, but hard to tell bytes to the code.

Examples: * In implementing rot13, I switched from f('A','Z') to f(65,90). In statically typed languages, it often only pays off, if you have enough invocations, to save a '.toChar' which gets necessary, by using Ints. So this will be hard to verify. * Sometimes a linebreak can be avoided:

def foo(a:Int)=a match{
case 42=> ...

can be written as

def foo(a:Int)=a match{case 42=> ...

surely something I would do, to win a golf, but spot it in other peoples code? In languages, which I don't know that well?

In a code-golf, you have to find a clever solution, to enter - for example - the range of 90-110 chars, and then you may optimize some whitespace away, and here a bit and there. Then you land at 70-90 chars. But it's not a very creative process.

You collect some tricks over the months, and can apply them on every 2nd or 3rd solution you provided.

Another one:

def s(a:String,b:String,c:String)=...

can be golfed by type S=String def s(a:S,b:S,c:S)=...

You have to count and measure, whether it is a win in the end - it consumes much time, and is not very funny or challenging.

To submit a solution - if we think about something like 'must be divisible by 10' you need to produce a solution, and then work on it, even if you would notice, that you can't reach for example another solution with 90 chars, because you have 124 chars. Your approach might be different, and your language, but you now have to find a way to add 6 more characters, which don't look superfluous.

The 400-questions-challenge was a kind of such a challenge, but it was hard to reach such a short code, and increasing the length of a solution is a new challenge, but only once.

I guess: As a category, it will not work.

• It's not creative in the long run
• It's too hard to check, especially, if you aren't master of a language
• It will lead to debates where to draw the borderline
• As to rules-mongering: this site doesn't seem to be so plagued. As to creativity: put "try a different algorithm" in your bag of tricks. – boothby Sep 5 '11 at 7:26
• As a C programmer, I totally agree. Lot's of tricks, such as replacing x!=y with x-y can be reversed to pad you code with characters. There's no challenge in getting an exact number. – ugoren Feb 1 '12 at 15:22

Just going to throw this out there as an idea. Why not try something a little more mixed?

Keep the intent of "lowest character count" (or similar goal), but as an additional criteria, the character count has to satisfy some extra condition.

For example, instead of "Code must be 100 characters", it could be "Shortest code with a character count that is a multiple of 10". Then, if you ended up with, say, 97 characters, you could pad the code an extra 3 characters for 100. Or you could see if you could cut off a whole 7 characters to end with 90 for a better victory. The end result is that you do get results that end in whole numbers, but still retains reasoning that inhibits putting fluff for fluff's sake.