4 ms·

Lesson? That’s at least a 40 year old piece of advice. People used to try to force me to write comments, and I would explain this to them. “Don’t get suckere

Lesson? That’s at least a 40 year old piece of advice. People used to try to force me to write comments, and I would explain this to them. “Don’t get suckered in by the comments-they terribly misleading. Debug only the code. Dave Storer Cedar Rapids, Iowa https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf https://moss.cs.iit.edu/cs100/Bentley_BumperSticker.pdf

mannykannot 4y ago
That risk also exists for identifiers, which can mislead to exactly the same degree as they can inform. To avoid this hazard, run the code through an obfuscator that substitutes meaningless identifiers, before looking at it.
doublerabbit 4y ago
Why not both? A comment may be terribly misleading but they explain the programmers logic to a certain function. Always handy to know. Each segment of code should have a diagram, a flow model, psuedo code, and comments. More the better.
- kangalioo 4y ago
  No, not the more the better. Comments should be easily updatable to keep up with code changes. If every refactor involves redrawing a bunch of fancy ASCII art, you'll either get less refactors, or outdated comments
  - doublerabbit 4y ago
    That's why you keep the old comments and write the changes within. "If loop does something" #rev1 "If loop did do something, it now does something twice" #rev2 "If loop doesn't do something, it does something three times" #rev3 "we loop three times because we processing supervariables" #rev4 And you have an wrong illusion of documentation. You don't need ascii diagrams. Why not a scribble in a sketch book? Whiteboards and photography exist. And the method above doesn't require you too redraw. You've already got the first and last revision. Besides, during an documentation cycle of your projects life-cycle is where you update all documentation. > you'll either get less refactors, or outdated comments If so, you're not disciplined enough. If your project is to be handed over down the line, more documentation is better than any and any documentation is better than none.
Consultant32452 4y ago
I once wrote some code so convoluted I put a mickey mouse ascii art in comments and a note that said "This is some Mickey Mouse BS. I hope you never have to maintain it." That's probably the only useful comment I've ever written.
peteradio 4y ago
At least with version control its feasible to track the original comment/code and understand intent. Although, I doubt an AI is able to do this yet.
andreareina 4y ago
Code that I wrote, that I subsequently had to ask: Why aren't you processing the first/last element of this sequence? Why are you casting this to a list when it's already a tuple? Why are you filtering out Decimal("NaN") from tests but not float ones?
IshKebab 4y ago
It's like the premature optimisation quote. The advice is technically sound, but it's still not really good advice because 90% of the times people quote it they're just using it as an excuse not to care about performance at all. Or in your case not to write comments at all. That's obviously a terrible idea.

mannykannot 4y ago

That risk also exists for identifiers, which can mislead to exactly the same degree as they can inform. To avoid this hazard, run the code through an obfuscator that substitutes meaningless identifiers, before looking at it.

doublerabbit 4y ago

Why not both? A comment may be terribly misleading but they explain the programmers logic to a certain function. Always handy to know. Each segment of code should have a diagram, a flow model, psuedo code, and comments. More the better.

kangalioo 4y ago
No, not the more the better. Comments should be easily updatable to keep up with code changes. If every refactor involves redrawing a bunch of fancy ASCII art, you'll either get less refactors, or outdated comments
- doublerabbit 4y ago
  That's why you keep the old comments and write the changes within. "If loop does something" #rev1 "If loop did do something, it now does something twice" #rev2 "If loop doesn't do something, it does something three times" #rev3 "we loop three times because we processing supervariables" #rev4 And you have an wrong illusion of documentation. You don't need ascii diagrams. Why not a scribble in a sketch book? Whiteboards and photography exist. And the method above doesn't require you too redraw. You've already got the first and last revision. Besides, during an documentation cycle of your projects life-cycle is where you update all documentation. > you'll either get less refactors, or outdated comments If so, you're not disciplined enough. If your project is to be handed over down the line, more documentation is better than any and any documentation is better than none.

Consultant32452 4y ago

I once wrote some code so convoluted I put a mickey mouse ascii art in comments and a note that said "This is some Mickey Mouse BS. I hope you never have to maintain it." That's probably the only useful comment I've ever written.

peteradio 4y ago

At least with version control its feasible to track the original comment/code and understand intent. Although, I doubt an AI is able to do this yet.

andreareina 4y ago

Code that I wrote, that I subsequently had to ask: Why aren't you processing the first/last element of this sequence? Why are you casting this to a list when it's already a tuple? Why are you filtering out Decimal("NaN") from tests but not float ones?

IshKebab 4y ago

It's like the premature optimisation quote. The advice is technically sound, but it's still not really good advice because 90% of the times people quote it they're just using it as an excuse not to care about performance at all. Or in your case not to write comments at all. That's obviously a terrible idea.