3 ms·

But then your code easily gets really wide, and you start committing heresy against the holy rule of 82.

by 50CNT 10y ago

nine_k 10y ago
If your functions are short, and logic straight, you usually don't end up with overly long lines and deep indentation. It's kind of similar to enforcing 8-space tabs, only with space consumed by a more expressive approach. I often notice that I can remove a comment line after renaming a few identifiers in the code below it, because the code starts to read self-explanatory enough.
- noobiemcfoob 10y ago
  > I often notice that I can remove a comment line after renaming a few identifiers in the code below it, because the code starts to read self-explanatory enough. Careful with that. I'm of the mind that the code author is incapable of describing how readable any codebase is. It's too easy to mistake your innate understanding of your own creation for readability.
  - chrisweekly 10y ago
    Also, while good names might obviate the need for "what" comments, they can't replace often-invaluable "why" comments.
  - nine_k 10y ago
    Good comments are usually about "why" and "what", while the code is about the "how". Code with descriptive identifiers often make code read like plain English.
- barrkel 10y ago
  Identifiers have the same problem that comments have: the thing identified can grow different responsibilities than its name. You don't get magically updating identifiers any more than you get magically updating comments. I've found that people who believe too much in the ability for identifiers to tell the story of the code factor too much stuff into separate non-reused functions. The result being that you can't take the name at face value; you need to push the current context onto your mental stack, drill into the identifier being called, and if necessary continue drilling, until the unstated side-effects and extra bits and bobs that always accrete in continuously maintained code become clear. This code is ironically harder to read than inlined code.

But then your code easily gets really wide, and you start committing heresy against the holy rule of 82.

by 50CNT 10y ago

But then your code easily gets really wide, and you start committing heresy against the holy rule of 82.

If your functions are short, and logic straight, you usually don't end up with overly long lines and deep indentation. It's kind of similar to enforcing 8-space tabs, only with space consumed by a more expressive approach. I often notice that I can remove a comment line after renaming a few identifiers in the code below it, because the code starts to read self-explanatory enough.

noobiemcfoob 10y ago
> I often notice that I can remove a comment line after renaming a few identifiers in the code below it, because the code starts to read self-explanatory enough. Careful with that. I'm of the mind that the code author is incapable of describing how readable any codebase is. It's too easy to mistake your innate understanding of your own creation for readability.
- chrisweekly 10y ago
  Also, while good names might obviate the need for "what" comments, they can't replace often-invaluable "why" comments.
- nine_k 10y ago
  Good comments are usually about "why" and "what", while the code is about the "how". Code with descriptive identifiers often make code read like plain English.
barrkel 10y ago
Identifiers have the same problem that comments have: the thing identified can grow different responsibilities than its name. You don't get magically updating identifiers any more than you get magically updating comments. I've found that people who believe too much in the ability for identifiers to tell the story of the code factor too much stuff into separate non-reused functions. The result being that you can't take the name at face value; you need to push the current context onto your mental stack, drill into the identifier being called, and if necessary continue drilling, until the unstated side-effects and extra bits and bobs that always accrete in continuously maintained code become clear. This code is ironically harder to read than inlined code.