this post was submitted on 06 Oct 2025
799 points (96.6% liked)

Programmer Humor

26762 readers
3086 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

founded 2 years ago
MODERATORS
 

Yeah learned this the hard way.

you are viewing a single comment's thread
view the rest of the comments
[–] QuizzaciousOtter@lemmy.dbzer0.com 44 points 1 day ago* (last edited 1 day ago) (1 children)
  1. Use git for any code you write. Yes, even a simple script.
  2. Commit and push often. More often than you think is reasonable. You can always rebase / fixup / squash / edit but you can't recover what you didn't commit.
  3. ???
  4. Profit.

Seriously, once you commited something to the repo it's hard to lose it. Unless you delete .git. But a this point frequent pushing has your back.

I know git can be hard to grasp in the beginning. It was hard for me too. I highly encourage everyone to put in the effort to understand it. But if you don't want to do that right now just use it. Just commit and push. It will pay off.

[–] Rooster326@programming.dev 8 points 22 hours ago* (last edited 21 hours ago) (3 children)
  1. (3) Get annoyed by constantly increasing Code Coverage Requirements on untestable (often legacy) code. Even afding comments requires code coverage go up! Line must always go up!
  2. Change step 2 to "Commit and push ONLY when absolutely necessary. Because adding comments often requires a rewrite of untestable code."
  3. Go back to Step 2 and wait for a major bug.

3 is not related to using git in any way. I'm not really sure what you mean in 4. I didn't mean making a lot of changes, I meant that you should not wait with committing until you have a finished feature / fix / whatever. Commit after each refactor, commit after adding a new testable unit. It's always better to have more checkpoints. If your team does code review, they will appreciate atomic commits too.

[–] fibojoly@sh.itjust.works 2 points 18 hours ago* (last edited 18 hours ago)

Our company "architects" decided we needed 80% coverage minimum. On a mostly .Net 4.8 codebase. Hundreds of programs used in prod, with barely any tests in sight.
It's a fucking nightmare.

[–] ExperiencedWinter@lemmy.world 2 points 19 hours ago* (last edited 19 hours ago)

Why would you care about code coverage requirements on a branch that is currently in development? My work in progress commits might not build because they don't even compile, let alone have passing tests. The only time I care about the build passing and meeting requirements is when I'm ready to create the pull request.

Also code coverage is a useless metric, but that's a different story.