The basic idea
In code golf, a task is stated, and the goal is to write the shortest program that completes it. The name borrows from the sport: as in golf, a lower score wins. A typical task might be to print a particular string, to compute a simple sequence, or to transform some input in a stated way. Everyone solves the same problem, and the ranking is decided by length.
Length is usually measured in bytes, though some challenges count characters instead. The difference matters when a language uses non-ASCII symbols, and good challenge descriptions say which they use.
What a good golf task looks like
A task works well for golf when it is precise, small and testable. The specification should say what input is given, what output is expected, and which edge cases must work. Vague tasks lead to arguments about whether an answer is valid, which spoils the fun. Many communities also ask that an answer work for every valid input rather than only the examples, since hard-coding the sample cases would be a cheap trick.
The same care appears in the broader subject of scoring rules, where small wording choices can change who wins.
How golfers shorten code
Golf is partly about knowing a language deeply and partly about thinking sideways. Common habits include:
- Dropping everything optional. Whitespace, long names, declarations and braces go wherever the language allows.
- Exploiting quirks. A value that is treated as true, a default that happens to be right, or an operator that does two jobs can save characters.
- Rethinking the algorithm. Often the biggest savings come from a different approach, not from trimming the same one.
- Reusing results. Computing something once and storing it can beat writing it twice.
These tricks usually make code harder to read. That is accepted in golf, though it is a different goal from clear, maintainable software. Golf is closer in spirit to obfuscated code than to everyday engineering, even if the motive is brevity rather than concealment.
Why odd languages appear
Newcomers are often surprised to see unusual languages in golf results. There are a few reasons.
First, some languages are designed for brevity. Dedicated golfing languages assign common operations to single bytes, so a task that takes many characters in a mainstream language might take a handful. They are built to win, and they say so.
Second, minimal languages can be surprisingly competitive on very simple tasks. A language with a tiny instruction set has no wasted syntax, so printing a fixed string or doing a bit of arithmetic can be short. Tape-based languages and grid-based languages sometimes do well when the task fits their model.
Third, golf is simply a fun place to show off a language. Many people enjoy the challenge of fitting a task into an unusual environment, and communities built around esolang challenges often include golf-style rounds as one format among several.
Fourth, there is often a separate leaderboard or category by language, so an answer in a niche language competes mainly against others in the same language. That lowers the pressure to beat the whole field and keeps the focus on craft.
Golf in a grid language
Grid-based languages add a twist. In a language where the pointer moves across a two-dimensional space, the layout of the code is part of the solution. A turn can replace a branch, a wrapped edge can replace a loop, and a single line can be reused in two directions. The geometry of the code becomes a resource, which is explored more in the discussion of geometric loops.
Shapes that look neat tend to cost extra characters, so the shortest answer is frequently a ragged, tightly packed layout. Compare this with advice about code layout for readability, which pulls in the opposite direction.
A small illustration, with no claim of being the shortest possible: the program "!iH",,,@ prints Hi!. The quoted part pushes three character codes, with H ending up on top, and each comma prints one character from the stack. Whether a program like this is competitive depends entirely on the task, and part of the fun is trying to beat any example you see.
Fairness and honesty
Good golf communities discourage a few things: exploiting loopholes in the rules, relying on a bug in a specific interpreter without saying so, and posting answers that do not actually run. A solution is normally expected to work with a standard, publicly available implementation of its language. It is also good manners to explain how an answer works. A cryptic submission with no notes teaches nobody anything, while a short explanation turns a score into a lesson. This is one of the quiet benefits of reading solutions written by others.
Getting started
If you want to try it, choose a task you already know how to solve in a familiar language. Write a normal solution first, then shorten it in stages, running your tests after every change. Only once you can see where the bytes are going is it worth switching to a stranger language. Expect to learn more about your chosen language in a few golf rounds than you would from a month of casual use, because golf forces you to read the documentation for every operator and ask what else it could do.
Treat the leaderboard as a side effect. The real reward is finding that one clever shortcut, and then discovering that someone else found a shorter one.