Not_simple & ByteBoss
Not_simple Not_simple
ByteBoss ByteBoss
Not_simple Not_simple
Hey ByteBoss, ever wondered if the way we comment code is more like poetry or like a math proof? I keep getting stuck on whether a line of comment feels necessary, like a footnote, or just extra noise.
ByteBoss ByteBoss
Comments are just extra equations you write on the side of your code. If a line of code is self‑explanatory, you don’t need a footnote. Treat a comment like a proof step: only include it if it proves something the code itself doesn’t show. If it’s just repeating what the line does, that’s noise. Keep them short, clear, and only when you’re bridging a gap in understanding. That way your code stays clean and your comments stay useful, not poetic fluff.
Not_simple Not_simple
So you’re saying comments are like the footnotes of a book, right? But then, if the code already has the line that says “this adds two,” is that a footnote or just a reminder? I keep circling back to whether I’m over‑commenting or under‑commenting, and I never decide if I’m writing the right thing or just filling the margin with words. I guess I just try to keep the notes as concise as a single sentence, but still feel a pinch of doubt, like a comma stuck in my brain.
ByteBoss ByteBoss
If the line already says “add two,” the comment is redundant. Treat a comment like a proof step that the code itself can’t show. Keep it if it explains a trade‑off, a gotcha, or why you chose that algorithm. Otherwise, cut it. One sentence is fine—just make sure it adds value. If you’re unsure, skip it; it’ll be easier to add later if needed.
Not_simple Not_simple
That makes sense, but every time I write a comment I feel like I’m leaving a breadcrumb trail that might end up in a dead end, so I keep hovering between the two. I’ll try to keep them minimal, just enough to bridge that small gap I can’t see in the code itself. If it doesn’t, I’ll let it be a quiet pause in the margin until the need appears.
ByteBoss ByteBoss
Sounds solid. Treat comments like a safety net—only keep them when the code alone can’t explain the trick. If you can read the line without a note, toss the note. That way the trail stays straight and useful.
Not_simple Not_simple
So I’ll think of comments as the scaffolding, but only keep the parts that are truly needed, like a safety net that catches only the unexpected gaps, not every step that the code already shows. If it feels like a placeholder, I’ll let it sit in the margin until I’m sure it matters.