Why patterns matter in a grid language
Most languages give you named functions, loops and variables. Befunge gives you a grid of single-character cells, a pointer that travels across it, and a stack. Everything else has to be built from those parts, and over time programmers settled on a small set of habits for doing it. Learning them turns a wall of punctuation into something you can read as a set of routes.
This page is a map. Each section names one recurring pattern and says what problem it solves. The detailed guides in this cluster work through each one with small examples. It assumes you already know the basic instructions; if not, start with the instruction set and the program stack, since every pattern below is just a particular way of combining them.
Moving data: the stack as workspace
Nearly every technique starts with the stack. Numbers are pushed, instructions pop their operands, and results are pushed back. Two instructions do a great deal of the housekeeping: : duplicates the top value so you can test it without losing it, and \ swaps the top two values so you can reach the one underneath. $ discards a value you no longer need.
A habit that pays off early is knowing, at every cell, how many values should be on the stack. The most reliable way to build that habit is tracing by hand with a short table of stack contents, and it is the method used in the worked countdown program. That walk-through is a good first read because it shows duplication, arithmetic and a test working together in a few cells.
Choosing a path: branching and skipping
Because the pointer simply follows arrows, a decision is a cell that sends the pointer one of two ways. The horizontal and vertical if instructions pop a value and pick a direction from it, which is the heart of conditional branching. Since they only distinguish zero from nonzero, comparisons usually combine them with the logical not and the greater-than instructions to turn a question into a 1 or a 0 first.
The other small steering tool is the trampoline instruction, #, which makes the pointer jump over the next cell. It looks minor, but it appears in many programs: it lets a test cell be used from two directions, lets a route cross another without interfering, and gives the compact loop idiom you will see in many examples.
Repeating work: loops from geometry
There is no while or for. A loop is a path that returns to a cell it already visited. A counted loop keeps a counter on the stack, decrements it each pass and leaves through a branch when it reaches zero. A conditional loop does the same with a different test, such as stopping when a newline arrives. The guide to Befunge loops covers both, including the question of whether the test belongs at the top or the bottom of the loop.
The shape of the loop on the page is part of the design. A tidy rectangle, with the test on one side and the return path on the other, is easier to follow than a path that doubles back through the middle of other code.
Text and input
Output of text uses a small trick. Quote mode, entered by a double quote and left by the next one, pushes the character codes of everything in between. Since the last character pushed ends up on top, strings are written backward or printed with a loop, and the guide on string mode explains both options and why the order surprises beginners. A classic Hello World program is the usual first exercise in this pattern.
Input is the mirror image. The instructions that read a number or a single character put a value on the stack, but real programs still have to deal with end-of-line characters, multi-digit numbers and ranges of valid values. Those details are covered in the guide on numeric input.
The grid as memory
The stack is awkward when you need to keep a value for a long time while other values come and go. The get and put instructions read and write the cells of the grid itself, so a spare cell can act as a variable. The guide on grid variables shows how to choose cells that the pointer never executes and how to keep track of which cell holds what. A related and more daring use is self-modifying code, where a program rewrites its own instructions; that is treated separately because it makes programs much harder to reason about.
Reuse without calls
Befunge has no call instruction, so a routine that is needed in two places has to be built differently. The usual approaches are to copy the code, to send the pointer into a shared section and then dispatch back using a value left on the stack, or to place a direction-changing cell with p before entering. Each has a cost in readability, and the guide on grid subroutines compares them.
Keeping it readable
The real limit on how large a Befunge program can grow is code readability. A few habits make a large difference: keep routes on straight lines, align turning arrows in columns, give each logical section its own region, and reserve a corner of the grid for data. The guide on code layout collects these. When a program still misbehaves, the usual culprits are listed under beginner mistakes, and a trace by hand will almost always find them.
A suggested order
If you are working through the cluster, a reasonable path is the countdown program first, then the guides on loops and conditional branching, which together give you most of what a simple program needs. After that, read about string mode and numeric input so your programs can talk to the outside world, then grid variables and subroutines when a program outgrows the stack. The trampoline and layout guides are short and can be read at any point.
Larger projects, such as the classic Befunge algorithms, are best attempted only once the loop and branch patterns feel routine. Those patterns are the vocabulary; the algorithms are the sentences you build from them.