Pine Script Pitfalls That Waste Sessions

[NYC88]

### Pitfalls that have wasted *my* sessions (and others')

1. **Repainting** — future leaks via non-confirmed bar logic; magical right edge → be suspicious.
2. **`calc_on_every_tick` surprises** — differs from bar-close alerts. Confuses people for days.
3. **Timezone sloppiness** — `time` vs exchange TZ; your OR is wrong by an hour and you call it a strategy problem. Done that. Felt bright.
4. **`request.security` lookahead** — classic foot-gun.
5. **Strategy tester fills** without commission/slippage — fantasy curves.
6. **Too many plots** — HUD lag on a thin laptop at the open.
7. **Alert JSON drift** — you changed fields, Python still expects `schema_v1`.
8. **`strategy.netprofit` as truth** for live stocks with different routing.

### Hygiene habits I tick

Code: Select all

[ ] Version comment at top
[ ] Inputs documented
[ ] Alert schema versioned
[ ] Bar magnifier / replay check on 3 dates
[ ] Compare bar-close vs tick assumptions explicitly

### Rule

If a Pine script pays you only when you stare at it, it is a dashboard. Label it that way and sleep better. Dashboards are fine. Lying about them is not.

Which Pine foot-gun has cost you the most hours?
Do you develop bar-close first, then carefully enable tick logic — or the other way around?
Anyone keep a changelog in the script header religiously?
Replay checks on 3 dates — part of your release ritual?

[Fairman]

These pitfalls have wasted my sessions too, especially timezone sloppiness on opening-range logic and tester fills without commission/slip on stocks.

Hygiene I tick before I trust a Pine helper for equity scalping:

- No repaint path on the right edge.
- Bar-close versus every-tick behavior understood for alerts.
- Exchange TZ for OR windows.
- Costs in the tester.
- Plot count low enough that the HUD doesn't lag at 09:30.
- Alert JSON versioned against whatever consumes it.
- Never treating strategy.netprofit as live routing truth.

One change I'd add: if the script is a HUD, treat it as a display. Entries still come from the written playbook, not from a color flip you didn't define.

A worked example of the timezone pit, because it cost me a full week once. I wrote a 5-minute opening range helper using the chart's timezone. My chart was set to my local time, so the "09:30" window was actually a different hour. The box drew a clean range every day, just around the wrong bars. It looked plausible, which is the dangerous part. The fix was to define the session with the exchange timezone explicitly, "America/New_York", and then check it against a known day by hand: the range should start on the 09:30 ET bar and end on the 09:35 ET bar. If the first bar's high in the box doesn't match the high you read off the chart for 09:30–09:34, the script is wrong.

Costs example, illustrative only: a strategy that averages 4 cents a share gross per trade looks fine in the tester with zero costs. Add a cent of slip per side and a small per-share commission and the edge can drop to roughly half. Put those numbers in the tester properties before you look at the curve, not after.

Failure modes beyond the list:

- Alerts set to fire on every tick for a bar-close condition, so they trigger and then un-trigger.
- Editing a script mid-session and forgetting the alert is still running the old version.
- Trusting a public script because the chart screenshot looks good.

When to skip Pine for a job entirely: if you need precise fill modeling, order routing logic, or tick-level execution checks, the tester isn't the tool. Use it for display and rough filtering, and keep execution questions in your broker logs.

Diagram: eight pits on one page.