There’s a very innocent-looking code snippet that gives me chills whenever I encounter it (especially in a largish TIs) that goes like this:

If (something something);
	Itemskip;
Endif;

nothing really complicated, nothing to wrack your brain about, nobody’s doing their best go at IRR calcs or any other fancy things, so why the dread?

The reason I shiver when looking at this (I just typed it and brrr) is that there’s no way for me to figure out that something was skipped after the fact.

So once this code gets into production and you’re asked ‘why isn’t this loaded properly’, you have to itemskip conditions in your head and figure out whether this record was dropped or not. Or re-run the process (in production, what?), but only if you know that the data stayed the same (it sometimes doesn’t). And most of the times you’re not asked ‘why is X not loaded properly’, you’re asked ‘why is the number Y’ and you’re wading through a whole slew of TIs trying to figure out what was skipped for what reason. And reasons would be absolutely genuine in 99.9% of the cases, it just takes ages to unpick.

What I find myself doing whenever I see this is adding a simple AsciiOutput

If (something something);
	AsciiOutput(debugLogFile, 'Skipping record because it fails something something condition : ', var1, var2, ...);
	Itemskip;
Endif;

where debugLogFile is something like processName_TimeStamp (add a Random int if you’re fancy). That way you’d at least be able to see why you skipped something in production half a year later.

These AsciiOutputs can really grow to cover details of calculations or exceptions (or as I say get battle-hardened) over time, saw a few projects with gigabytes of detailed logs generated every night. And I was truly thankful they were there when I needed to trace something.