←back to thread

1455 points nromiun | 2 comments | | HN request time: 0.545s | 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 #
1. Waterluvian ◴[] No.45076149[source]
The challenge I have these days is deciding what belongs in code and what goes into design documentation and technical manuals.

I generally find that comments in code should explain why the code is doing non-obvious things. “This gets memoized because it’s actually important to maintain referential identity for reason X.”

replies(1): >>45076928 #
2. jijijijij ◴[] No.45076928[source]
The problem is, a year later the obvious things are not obvious anymore :D