[svat]

Another reason for shortening code in programming contests (apart from being able to type and edit/iterate faster) is that it helps you avoid errors. For example, in the heat of the moment and under intense time pressure (e.g. you have finally figured out the algorithm to solve the problem, but you have only 13 minutes left to implement it or whatever), it's easy to write code like this:

    for (int i = 0; i < n; ++i) {
        for (int j = 0; i < n; ++j) {
            ...

instead of what was intended (j < n).

So if you have (in your pre-written library of snippets) a macro like

    #define FOR(i, n) for(int i = 0, _n = n; i < _n; ++i)

then you can write:

    FOR(i,n) FOR(j,n) {
        ...

(the _n in the macro is for cases like FOR(i, v.size()) to avoid recomputation) and at least avoid that particular error. Of course other sorts of silly errors are still possible; some examples here: https://www.quora.com/What-is-the-worst-mistake-youve-made-i...

[legohead]

Thanks for the example, I actually like this FOR macro. It was mostly the things like 'typedef long long ll;' or 'typedef pair<int,int> pi;' that bothered me.

And I don't mean to say the whole thing is bunk. I found some really good info farther into the book, especially about algorithms, which I think will help towards interviewing candidates.

[irundebian]

I'm not sure that you avoid errors by forcing yourself to write short code. With C macros.

[loup-vaillant]

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)

[irundebian]

In this case the use of macros may increase the readability or assurance of the code, still there are a lot of cases where macros can easily lead to bugs: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pa...

[loup-vaillant]

Of course. You will note I only went macro to prevent an error I already made. C macros suck, I don't use them lightly.

[yodsanklai]

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.

[kevmo314]

Well, when your code has a lifetime of five hours max, readable doesn't matter, correct does.