←back to thread

1457 points nromiun | 1 comments | | HN request time: 0s | source
Show context
Buttons840 ◴[] No.45075079[source]
It's been said: "Document the why, not the what."

I have a hard time separating the why and the what so I document both.

The biggest offender of "documenting the what" is:

    x = 4  // assign 4 to x
Yeah, don't do that. Don't mix a lot of comments into the code. It makes it ugly to read, and the context switching between code and comments is hard.

Instead do something like:

    // I'm going to do
    // a thing. The code
    // does the thing.
    // We need to do the
    // thing, because the
    // business needs a
    // widget and stuff.
    
    setup();
    t = setupThing();
    t.useThing(42);
    t.theWidget(need=true);
    t.alsoOtherStuff();
    etc();
    etc();
Keep the code and comments separate, but stating the what is better than no comments at all, and it does help reduce cognitive load.
replies(6): >>45075259 #>>45075314 #>>45075395 #>>45076149 #>>45079235 #>>45080058 #
marginalia_nu ◴[] No.45075259[source]
I generally don't mind documenting both when it's merited. Sometimes you need to clarify the why, occasionally you need to clarify the what.

I think comments in general are underrated. You don't need to annotate every line like a freshman programming assignment, but on the other hand most supposed self-documenting code just isn't.

replies(1): >>45075299 #
mastermage ◴[] No.45075299[source]
sometimes you do some wack magic in just one line of code, sometimes thats necessary for performance or because what you are trying todo is inherently wack magic. Example the fast inverse square from quake. Insane magic and if you just document does inverse square approximately people would freak out. So sometimes when wack magic is used explain the wack magic (as concise as reasonable)
replies(1): >>45075386 #
marginalia_nu ◴[] No.45075386[source]
Yup.

I've got a function the gist of which is

  if (!cond())
    return val;

  do {
    // logic
  } while (cond());

  return val;

This looks like it could be simplified as

  while (cond())
    // logic
  }
  return val;
But if you do you lose out on 20% of performance due to branch mispredictions, and this is a very hot function. It looks like a mistake, like the two are equivalent, but they are actually not. So it gets a comment that explains what's happening.
replies(1): >>45075647 #
brokencode ◴[] No.45075647[source]
That feels like.. something the compiler should be optimizing for you? I would certainly be among those questioning this code.
replies(1): >>45075671 #
marginalia_nu ◴[] No.45075671[source]
The compiler can't know from the code alone which branch is more likely. This is a property of the input data and not the code. Really advanced JIT compilers can sometimes do those types of optimizations, but this is a fairly rare scenario.
replies(2): >>45076830 #>>45076966 #
1. whitehexagon ◴[] No.45076966{3}[source]
The other day I spotted Zig has @branchHint, not tried it yet, my code isnt that hot!