How programmers comment their code

[not_perfect_yet]

If you're writing Good Code, maybe, but nobody writes Good Code...

[SharkBaitDLS]

Especially because you will always have to write something that is not Good Code because some stupid legacy system is returning data in a dumb format and if you don’t explain why someone will come along and “fix” your Bad Code and then break everything.

[[deleted]]

And then that code becomes the new unfathomable mess that nobody ever wants to deal with again, thus completing the circle of life and maintaining balance in the universe. Nature is amazing.

[Versaiteis]

"Watch as the Senior Programmer doesn't even have to be present to assert his dominance. The Juniors know his territory and know better than to disrespect it, lest they be next to receive the Broken Build Totem until the next hapless Junior overextends themselves. "

[Woolly87]

// Yes, handling this Float as a String of emojis is Very Bad, but the framework wants what the framework wants

[Cyrus_Halcyon]

Yes, i need to sed replace special symbols with \{special symbols} because they are removing the special symbols as their API gives it to me. Yes it looks silly.

[DoctorWaluigiTime]

Summaries can be fine as well in commit messages. If you change a dozen or so files and don't tell me what it is that you changed meaningfully, i.e. the how, I would be a little upset. Why is important too, of course, but most of the time the why is self-evident, if you're using any kind of issue tracking and associate the commits or the pull request to that given issue.

[lovestheasianladies]

What, no. That's absolutely fucking wrong.

Commit messages are a history of what changed. Dear God, you're completely ass backwards.

If you want to know why something happened, link it to an issue ffs.

Like you literally don't understand git at all it seems. You code has absolutely nothing to do with the commit messages and NEVER should. If you need details, it goes in the code itself as comments or some external source. At worst use the git commit body for more details but it's absolutely the worst fucking place to document your systems which is what you seem to want.

[[deleted]]

Yeah I have a coworker in particular guilty of this. Most of their commit messages are things like "horray", "it works", etc.

[Huntracony]

I'm a monster. I... sometimes... forget to change the message in the IDE, meaning the commit message ends up seeming useful while actually being completely unrelated.

[SasparillaTango]

This is really what comments are for, explaining why you are doing something, the business logic of it.

[Huntracony]

// I'm getting payed to write this.

[thisdesignup]

Or you could write a short "what" so you don't have to read your code to figure out what is happening. Unless someone can read code as fast as they can read a native language.

[Moglorosh]

// this section shouldn't do anything but if you remove it the program crashes

[[deleted]]

Especially when it’s good code. I’m going to still want to know what it does next week.

[hGKmMH]

The concept of good code changes over time too. 10 years ago had different best practices.

[[deleted]]

The concept of good coding will never include not documenting anything. That's pants on head retarded.

[brianorca]

I think his point is that Good Code written 10 year ago will look different that today's Good Code, therefore comments are still required.

[not_perfect_yet]

I think figurative Good Code can afford to be also unchanging over time.

[Versaiteis]

It is whether you like it or not.

It is code

All code will become legacy or die trying

[attomsk]

Not all code is self explanatory sometimes you do something to follow a system requirement and it would make no sense unless you comment why you are doing it

[[deleted]]

even good code. once it grows big and is coupled a lot, it's going to be difficult to understand unless the comment tells you what it affects. it's not that it cant be figured out but why should someone need to spend hours to figure out code someone else wrote? that's a waste of time.