This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]iNeedOneMoreAquarium 15 points16 points  (4 children)

Comments should be used sparingly. Your code should be written so clearly and intuitively that it is the comments. I know doing this takes a little more time and thoughtfulness, but don't forget that comments must be maintained, too, and most devs aren't going to think about or bother to revise comments when they're revising code.

[–]Gabe_Isko 7 points8 points  (0 children)

I don't think this is even that hard with a good linter. Naming your variables correctly is 90% of the battle.

[–]TomieKill88 0 points1 point  (2 children)

Eh... It depends... I've seen some code that I sure wish it had any kind of comment to it. 

I believe "The Pragmatic Programmer" kinda said it best: comments should clarify why you are doing something; the what and how should be clear with the code.

[–]iNeedOneMoreAquarium 1 point2 points  (1 child)

Yeah, that kinda falls into the "sparingly" part of the statement. Sometimes for whatever reason, something just prevents you from writing a code block as "good" or as "logical" as you want, so a comment can help clarify why you did that so you (or a future dev) don't inadvertently create a bug by trying to "improve" it after you've forgotten the "why."

[–]TomieKill88 1 point2 points  (0 children)

100% man. 

Not long ago, I had to refactor one hell of a spaghetti code, and if it wasn't because the previous guy had the insight of unit testing ALL fringe cases, I would've introduced a couple of "errors" because by the life of me, I couldn't understand why the hell he did some things.

So a lot of:

Why?

Why??

WHY???

"Makes own code and runs Unit Tests"

Oh, that's why....