Programmer Humor

19817 readers

89 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

Keep content in english
No advertisements
Posts must be related to programming or programmer topics

founded 2 years ago

MODERATORS

[email protected]

1097

My Git Knowledge (lemm.ee)

submitted 9 months ago by [email protected] to c/[email protected]

177 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 51 points 9 months ago (1 children)

I had a programmer lead who rejected any and all code with comments "because I like clean code. If it's not in the git log, it's not a comment."

Pretty sure I would quit on the spot. Clearly doesn't understand "clean" code, nor how people are going to interface with code, or git for that matter. Even if you write a book for each commit, that would be so hard to track down relevant info.

[–] [email protected] 31 points 9 months ago (3 children)

Yeah, I think that guy only got a superficial understanding of what Uncle Bob was saying.

My policy as a tech lead is this: In an ideal world, you don't need the comment because the names and the flow are good. But when you do need the comments, you usually really need those comments. Anything that's surprising, unusual, or possibly difficult to understand gets comments. Because sometimes the world is not ideal, and we don't have the time or energy to fully express our ideas clearly in code.

My policy on SCM logs is that they should be geared more towards why this commit is going in, not what is being done. And what other tickets, stories, bugs it relates to.

[–] [email protected] 20 points 9 months ago (1 children)

Lead of a small team of scripters here. The "Why. Not What" is defo a good way of encouraging cleaner code.

Had to request changes recently on a PR like this, big function with comments telling me what it was doing. When they resubmitted for review they had broken it down into smaller functions with good variable/function naming. following what was going on was much easier

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

Same strategy here, but recently found myself commenting on the “what”. There was a perfect built-in, but not really readable and I couldn’t figure out how to make it readable, so fine

[–] [email protected] 6 points 9 months ago

But when you do need the comments, you usually really need those comments.

It’s nice to see you sharing my experience. My code is either uncommented or very severely commented with comment-to-code ratios of 10:1 or more. I hate the files that are soo green… :(

[–] [email protected] 5 points 9 months ago (1 children)

We solve that problem using naming conventions. Branch names must start with the issue key (we use Jira). You don't do anything in that branch that's not part of that issue. If you do, you must prefix the commit message with the issue key that it goes with. The commit itself identifies what changed. The Jira issue provides all the backstory and links to any supporting materials (design docs, support tickets, etc). I have to do a lot of git archeology in my role, and this scheme regularly allows me to figure out why a code change was made years ago without ever talking to anyone.

[–] [email protected] 3 points 9 months ago

To be honest, when I ask a candidate about git, I’m looking for them to describe this workflow.

Heck, I have a new person who I tasked with minor config change, just to make sure she knows how to use git in a professional environment