# Tips for golfing in LOLCODE

What general tips do you have for golfing in LOLCODE? I'm looking for ideas that can be applied to code golf problems in general that are at least somewhat specific to LOLCODE. (e.g. "remove comments" is not an answer). Please post one tip per answer.

• I had thought about posting this myself. It's actually not impossible to golf in LOLCODE. Commented May 9, 2015 at 18:39
• Somewhat embarassingly, my second and third highest upvoted answers are in LOLCODE. So I will take this opportunity to share everything I know. Commented May 9, 2015 at 18:51

Define variables using the syntax variable R value rather than I HAS A variable ITZ value.

If you want to set a variable n equal to 1,

n R 1


is only 5 bytes, whereas

I HAS A n ITZ 1


is 15 bytes.

• But then you lose the whole point of LOLCODE! Commented May 9, 2015 at 18:47
• @Optimizer: To be fair, when is there ever a point to LOLCODE? Commented May 9, 2015 at 18:50
• The point of LOLCODE is for the lols, of course. Commented May 9, 2015 at 19:01
• @ace: Okay, you got me there. Commented May 9, 2015 at 19:01
• lol​​​​​​​​​​​​ Commented May 10, 2015 at 0:47

In many cases it's shorter to read variable values from STDIN rather than defining a function. However, note that GIMMEH, which reads input from STDIN, always reads a YARN (i.e. string). But you can take advantage of LOLCODE's dynamic typing and add 0 to convert to a NUMBR.

For example,

GIMMEH n
n R SUM OF n AN 0
... (operations on n)


Defining n is 26 bytes, including newlines. Compare this to a user-defined function:

HOW DUZ I f YR n
... (operations on n)
IF U SAY SO


This requires 28 bytes.

Note that you could also multiply by 1 to convert to a NUMBR, but that requires 4 more bytes than the sum:

GIMMEH n
n R PRODUKT OF n AN 1

• But n IS NOW A NUMBR is one byte shorter than n R SUM OF n AN 0 Commented Jul 22, 2016 at 16:53
• @LeakyNun Which implementation has that? I haven't seen it before. Commented Jul 22, 2016 at 23:52

In many LOLCODE implementations, such as the one on repl.it, HAI and KTHXBYE, which begin and end programs respectively, are unnecessary. In implementations in which they are necessary, the version number after HAI isn't necessary (e.g. HAI 1.2).

Similarly, the STDIO library is typically loaded by default, so CAN HAS STDIO? is also unnecessary.

When printing the value of a variable to STDOUT, consider the following:

VISIBLE variable


is much shorter than

VISIBLE ":{variable}"


Also, whenever a trailing newline is acceptable,

VISIBLE variable


which includes a trailing newline by default, is shorter than

VISIBLE variable!


which suppresses the newline.

Many operators have optional ANs in between them, as defined in the spec. For example:

SMOOSH "hello" AN ", world" MKAY


can be turned into this:

SMOOSH "hello" ", world" MKAY


Other operators that support this include BOTH, EITHER, WON, ALL, ANY, BOTH SAEM, and DIFFRINT. For some reason, the numerical operators don't allow you to remove the AN, though.

The spec also says, specifically for SMOOSH, that:

The line ending may safely implicitly close the SMOOSH operator without needing an MKAY.

Meaning this code should also be valid:

SMOOSH "hello" ", world"


However, the current version of lci doesn't seem to accept this behaviour :(

LOLCODE (surprisingly) doesn't actually need indentation, meaning you can turn this:

HOW IZ I FIB YR N
I HAS A SML ITZ SMALLR OF N AN 1
BOTH SAEM N AN SML
O RLY?
YA RLY
FOUND YR 1
NO WAI
I HAS A FIRST ITZ I IZ FIB YR DIFF OF N AN 1 MKAY
I HAS A SECOND ITZ I IZ FIB YR DIFF OF N AN 2 MKAY
FOUND YR SUM OF FIRST AN SECOND
OIC
IF U SAY SO


Into this:

HOW IZ I FIB YR N
I HAS A SML ITZ SMALLR OF N AN 1
BOTH SAEM N AN SML
O RLY?
YA RLY
FOUND YR 1
NO WAI
I HAS A FIRST ITZ I IZ FIB YR DIFF OF N AN 1 MKAY
I HAS A SECOND ITZ I IZ FIB YR DIFF OF N AN 2 MKAY
FOUND YR SUM OF FIRST AN SECOND
OIC
IF U SAY SO