Communicate Through Commit

  • Comments posted to this topic are about the item Communicate Through Commit

  • 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

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • 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.

  • 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"

  • 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

  • I hear you Chris. Where I currently work we require someone enter a message in the check-in. I've seen many messages that say, "asdf".

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply