4 ms·

> You can tell everything with code, given enough time and resources. That's just not true. There are infinite many ways to write the exact same thing. Your

> You can tell everything with code, given enough time and resources. That's just not true. There are infinite many ways to write the exact same thing. Your code can never say why it's like it is, why this approach was chosen and not another. > […] the comments explaining how a particularly hairy piece of code worked […] This kind of comments are the bad ones actually. Your code should be clear enough that it's easy to see how it works and what is happening. The rule is actually very simple, and I don't get it why so many people have issues with following it. "Code says what and how, comments say why."

TedDoesntTalk 4y ago
> The rule is actually very simple Why does there have to be rules about when to comment? I comment frequently about whatever the hell I want. Don’t like it? Then don’t read the comments. Very simple, just like your rule.
- still_grokking 4y ago
  Useless comments are like useless code: They create an unnecessary (and therefore costly) maintenance burden. If you think you're the smartest person on the planet so "rules" (or better said best practices) don't apply to anything you do I hope nobody ever needs to collaborate with you. All the "rules" are there for a reason! No, you're not free do to whatever you like in a professional setting. For example when you're operating machines you need to follow safety regulations. Otherwise you could even end up in jail quite quickly.
  - TedDoesntTalk 4y ago
    > All the "rules" are there for a reason! Except in this case, you've made up the rule. It is not an axiomatic rule like gravity. I want different rules. So unless we work together, your rules don't apply to me.
otikik 4y ago
> There are infinite many ways to write the exact same thing. I agree with that. I don't think that makes things impossible. Only more difficult. > Your code can never say why it's like it is, why this approach was chosen and not another. If the why is important, given enough time and resources, someone will eventually complain that something is not working and someone will be tasked to "fix it". It may take them weeks, but they will eventually figure out the why. > Code says what and how, comments say why. If we are considering only quality vs quality, I agree. But there's also quantity. When the how is complicated enough, it is indistinguishable from a why. You will hear the reviewers ask outloud: "But WHY is this done this way?". Even if the problem is merely algorithmic/technical and the code is doing exactly what it's supposed to do. Then you have two options: spend a potentially significant time refactoring things (which is always the right choice, given enough time and resources) or spend 10 minutes writing a comment with what you learned, and moving on to the next problem.

TedDoesntTalk 4y ago

> The rule is actually very simple Why does there have to be rules about when to comment? I comment frequently about whatever the hell I want. Don’t like it? Then don’t read the comments. Very simple, just like your rule.

still_grokking 4y ago
Useless comments are like useless code: They create an unnecessary (and therefore costly) maintenance burden. If you think you're the smartest person on the planet so "rules" (or better said best practices) don't apply to anything you do I hope nobody ever needs to collaborate with you. All the "rules" are there for a reason! No, you're not free do to whatever you like in a professional setting. For example when you're operating machines you need to follow safety regulations. Otherwise you could even end up in jail quite quickly.
- TedDoesntTalk 4y ago
  > All the "rules" are there for a reason! Except in this case, you've made up the rule. It is not an axiomatic rule like gravity. I want different rules. So unless we work together, your rules don't apply to me.

otikik 4y ago

> There are infinite many ways to write the exact same thing. I agree with that. I don't think that makes things impossible. Only more difficult. > Your code can never say why it's like it is, why this approach was chosen and not another. If the why is important, given enough time and resources, someone will eventually complain that something is not working and someone will be tasked to "fix it". It may take them weeks, but they will eventually figure out the why. > Code says what and how, comments say why. If we are considering only quality vs quality, I agree. But there's also quantity. When the how is complicated enough, it is indistinguishable from a why. You will hear the reviewers ask outloud: "But WHY is this done this way?". Even if the problem is merely algorithmic/technical and the code is doing exactly what it's supposed to do. Then you have two options: spend a potentially significant time refactoring things (which is always the right choice, given enough time and resources) or spend 10 minutes writing a comment with what you learned, and moving on to the next problem.