this post was submitted on 10 Jun 2024
282 points (94.9% liked)

Programmer Humor

19594 readers
891 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
282
submitted 5 months ago* (last edited 5 months ago) by [email protected] to c/[email protected]
 

Comment from my group project teammate. You don't need to comment every line lol

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 73 points 5 months ago* (last edited 5 months ago) (11 children)

Writing good comments is an art form, and beginner programmers often struggle with it. They know comments mostly from their text books, where the comments explain what is happening to someone who doesn't yet know programming, and nobody has told them yet that that is not at all a useful commenting style outside of education. So that's how they use them. It usually ends up making the code harder to read, not easier.

Later on, programmers will need to learn a few rules about comments, like:

  • Assume that whoever reads your code knows the programming language, the platform and the problem domain at least in general terms. You are not writing a teaching aid, you are writing presumably useful software.
  • Don't comment the obvious. (Aside from documentation comments for function/method/class signatures)
  • Don't comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments. Reserve the "what" style comments for where that just isn't possible.
  • Do comment the why. Tell the reader about your intentions and about big-picture issues. If an if-statement is hard to parse, write a corresponding if clause in plain English on top of it.
  • In some cases, comment the "why not", to keep maintenance programmers from falling in the same trap you already found.
[–] [email protected] -4 points 5 months ago (3 children)

Do comment the why

In this day and age of source control I don’t think this is fully necessary. If you want to know the why, you can look into the commit history and see which ticket is connected to it. There you might even see the discussions around the ticket as well. But this requires good source control discipline.

It has helped me many times.

[–] [email protected] 11 points 5 months ago* (last edited 5 months ago) (2 children)

Why not put the "why" in a comment and save people the job of dredging through old commits and tickets to figure out what the code is for? I'd thank someone for saving me the hassle.

[–] [email protected] 1 points 5 months ago

In any modern IDE "dredging through old commits" means clicking a single button to see who last changed the line. From there it often makes sense to go look at the PR to see a higher level of what was changed. You cannot include all of that context in a single comment.

load more comments (1 replies)
load more comments (1 replies)
load more comments (8 replies)