Here's a real world example:

https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a...

So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus:

  crypto_stuff(stuff_ctx *ctx) {
      // stuff
      crypto_wipe(ctx, sizeof(ctx)); // BUUUG!!
  }

See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops.

Now I write this instead:

  crypto_stuff(stuff_ctx *ctx) {
      // stuff
      WIPE_CTX(ctx); // correct!
  }

The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am willing to give 100€ to anyone who finds such an error, see https://monocypher.org/quality-assurance/bug-bounty)

When you write "FOR(i,n)", instead of "for (int i = 0; i < n; i++)" you only write "i" once instead of 3, which makes it less likely to make mistakes.

That being said, I've found that competitive programmers sometimes write extremely ugly code. It's surprising to see how they are able to solve such complex problems, and yet can't (or don't value) write readable and structured code. Maybe they are so sharp that they don't feel the need to make their code more readable.