Why the same mistakes keep appearing
Befunge asks you to keep two things in your head at once: where the pointer is going, and what the stack holds. Most beginner errors come from losing track of one of them. The mistakes below are common because they are natural, not because the people making them are careless. Each comes with a quick way to check and fix it.
1. Forgetting that the pointer keeps moving
The pointer does not stop at the end of a row. It runs on to the edge and wraps around. If your program has no @ reachable along its path, it will loop forever. If it has a stray character, it may do something odd on the way.
Fix: follow the pointer from the top-left cell with your finger, and confirm it reaches an @. If it never does, a missing arrow is the usual cause.
2. Mixing up the arrows
The v is a letter, and the ^ is a caret. The letter v points down, which makes sense on the grid, but it is easy to miss when it sits among other letters inside text. Also, < and > can be confused when you are tired.
Fix: after writing each turn, read it aloud, such as “turn down here, then go right at the bottom”. If you want a more thorough treatment of this, see the notes on pointer direction.
3. Pushing values in the wrong order
Subtraction and division use the lower value first and the top value second. So 52- gives 3 (5 minus 2), while 25- gives negative 3. Beginners often reverse these, especially when thinking in the usual infix way.
Fix: read the numbers left to right, and treat the operator as applying to everything pushed before it. Test small numbers first, so mistakes are obvious.
4. Printing with the wrong command
The dot prints a number, followed by a space. The comma prints a character. If you push 72 and use ,, you see the letter H. If you use ., you see 72 followed by a space.
Fix: ask yourself whether you want a letter or a number before choosing the output command.
5. Writing strings in the wrong direction
Text pushed in string mode goes onto the stack first-to-last, so the last letter ends up on top. Printing by repeatedly popping reverses the text. A beginner who writes "Hello" and prints will see the letters backward.
Fix: write the text in reverse inside the quotes when you plan to print by popping it. The article on writing Hello World shows this step by step.
6. Forgetting to close the quote
A single double quote starts string mode, and nothing ends it until the next double quote. If you miss the closing one, the pointer keeps pushing characters from the rest of the row, including your arrows, which no longer act as arrows.
Fix: count the quotes on each row; the number should be even.
7. Misreading the decision commands
The underscore sends the pointer right if the popped value is zero and left otherwise. The vertical bar sends it down on zero and up otherwise. It is common to get zero and nonzero backward, so the branch takes the wrong path.
Fix: write a small note beside the cell, such as “0 means right”. The same idea appears throughout conditional branching.
8. Leaving values on the stack
A loop that pushes more than it pops will leave extra values behind, which can confuse later steps. Meanwhile, loops that pop too much can reach an empty stack, which reads as zero and can hide a bug.
Fix: after each section, write down what the stack should look like. This is the same discipline that interpreter writers use when they think about stack underflow.
9. Assuming the stack is empty at the start
It is empty at the beginning, but after loops and branches you might not be sure. A decision instruction that reads leftover junk can behave unpredictably.
Fix: use $ to discard values you no longer need, or check by tracing.
10. Getting g and p coordinates wrong
The coordinates for g and p are taken in a particular order: y is on top, x is under it. Reversing them reads or writes the wrong cell, which can overwrite your own code.
Fix: push x first and y second, every time, and keep the storage area far from the instructions.
11. Crowding the layout
Cramming code into the smallest space makes it hard to see what is going on. Two paths that cross by accident can interfere with each other.
Fix: spread the code out until it works, then tighten it if you really want to. A thoughtful code layout makes errors easier to spot.
A habit that prevents most of these
Almost every item above is caught by following the program by hand with a small input. Keeping a simple table of the pointer position and the stack, as described in the article on tracing a program by hand, will quickly show where reality departs from what you intended. When that is not enough, general grid debugging methods can help narrow down the problem.
Mistakes in Befunge are not a sign that you are doing badly. They are part of the process, and each one teaches you something about how the pointer and stack really behave.