Many new users with zero programming experience struggle when their formula works incorrectly. Here are few hints that everyone should use to make finding errors easier.
First of all: you have to get insight into what the formula is actually doing, not what you think it does.
Typically new user has no idea what is happening inside. Pretty often you make an assumption that things work one way but in fact they work differently. Do not assume things. Check the manual and if it is still unclear - try it. If you are want to use a new AFL function, use it alone in chart or exploration and experiment a bit to learn how it works. There are few tools that allow you to get that insight:
Inspecting the Detailed Log will tell you precisely what signals are generated each and every bar, what are position scores and when / why signals are ignored (due to constraints such as insufficient funds)
This helps understanding code structure. As mentioned in this thread, sometimes incorrect indentation leads to misunderstandings. Using Prettify uncovers true structure of the code and helps finding problems with program flow.
The debugger allows you to single-step thru your formula, set breakpoints, watch the content of your variables and more
Keep in mind that debugging your own code is your task. If you want to use the formula for trading you absolutely must understand how it works. If you rely on somebody else to fix errors in your code you will not understand what is going on and you risk your money. So in your own best interest, spend time on debugging your code yourself.
For me, this is the single best piece of advice on how to use these trouble shooting tools, that I have learned. I am now able to see down into the roots of my systems. Where before I was only able to see the trunk and branches and only hope the roots were solid.
Please consider this a “standing thank you” for this and all of your thinking, building and implementation of AB.
The other item I would include would be use of the Detailed Log to identify what the backtester is doing internally on each bar. This can be invaluable when trying to figure out why an expected entry or exit isn’t occurring, or an unexpected one is.
Most of the comments here, so far, deal with tools, debugger, plots, etc. Instead, below, I present a more general approach to debugging, and design in general. (I know what I am talking about, >45 years as a successful electronic design engineer, hardware and software).
"Divide and Conquer"! When you are having problems with your code, reduce it to the smallest snippet that still is problematic. In fact, even if you are not having problems (yet), you may start with small snippet and test, add, test, add, test,... until you are successful or you found that small addition that is problematic.
Start with a "Written Plan" in your native language. This may be in the form of a specification, flow diagram, block diagram, hierarchy of user commands or routine calls, whatever you are most comfortable with and which you are most likely to refer to as you proceed. You are not limited to just one of the proceeding forms.
BTW, 1. above is sometimes referred to as "Bottom Up", while 2. as "Top Down". Personally, I have done both, and still find both to be necessary and fun.
If you have many years of experience, and are responsible for a 'product', you best start with 2. above. And might never do 1. yourself, but assign to others instead.
If you are a true newbie, you best start with 1. above, but try to venture into as much of 2. as you can. At your level it is smart to start with the easiest stuff (builds familiarity, confidence, and good technique).
5 - more. Look over others' shoulders'. Learn from their successes and mistakes. Ask questions only after you have tried everything else first.
"One learns little from one's own successes, but most from one's own mistakes". Mistakes should be like voting, "early and often".
Another solution, which in my opinion can be useful in some specific cases, is using Say() function. This time you don't use any visual output, but you simply hear what's going on and you are notified about some events right away even if you don't look at the screen or when for example AmiBroker is minimized.
Speak requests can be queued (spoken when previous requests are done) or next event can purge all previous speak requests. Of course such notifications can also be highly customized and provide detailed information.