July 23, 2020 at 12:00 am
Comments posted to this topic are about the item Communicate Through Commit
July 23, 2020 at 3:28 pm
This just sounds like the basic skill required for properly documenting any code but slightly extended. The comments should explain the What and Why. You can read the code for the "How".
My rule of thumb is that if you remove all of the code, you should be able to create a functional flowchart from the comments that remain.
In fact, that's how I start most of my code. I'll write the comment to explain to myself what I'm trying to do before I write the code. Yep... there are times when you have to change the comments because you changed your mind. If you're prone to it, stop using that silly excuse as a reason to avoid comments. Just do it. It's a part of the job.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2020 at 3:48 pm
I do agree with you that good commit messages are important. I am guilty of not writing good check-in (we using TFVC, instead of Git). Often I am too verbose. I'm working at it. And even when I'm brief I tend to just write what I've done, rather than why I did it. Again, a good reminder.
But as an aside I've found that developers getting together to agree upon standards is very rare.
Kindest Regards, Rod Connect with me on LinkedIn.
July 23, 2020 at 3:56 pm
This is great advice! All too many times I've seen commit messages that are generic like "fix" or something else fairly useless. The worst is if you work someplace where everything is feature branched, and if people use bad messages, then the almost entire history just says "merged from branch X"
July 23, 2020 at 4:01 pm
Standards are hard here. More, I think discussing whether a particular comment is helpful or not helps the team decide what is important and how to structure them
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply