That’s when you set the intern’s IDE to preserve the line endings.
this post was submitted on 29 Mar 2024
2 points (100.0% liked)
Programmer Humor
19149 readers
1214 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 1 year ago
MODERATORS
sets the diff to ignore whitespace
Lines changed: 3
The pipeline should handle formatting. No matter how you screw it up, once you commit, it gets formatted to an agreed upon standard.
Or auto rejected when the format doesn't fit.
Net removal of 1500 LoC...
I'm gonna make you break this up into multiple PRs before reviewing, but honestly, if your refactoring reduced the surface area by 20% I'm a happy man.
it's just removed unit tests that didn't work any more....
Love it when my coworkers reformat the code style, making it nigh impossible to understand what they actually changed, while greatly inflating their “contribution.”
It also blows away the git blame, making it hard to know who actually changed that one critical line of business logic 3 years ago that you need to understand before trying to fix some obscure bug.
I have one coworker who does this constantly and if you just looked at git blame, you’d think he wrote the entire code base himself.
First things first: Your team needs a coding style.
Also: With git reflog ignore-revs you can filter commits that only adapt the style.
And while we're at it, check out the -C -C -C flag for git blame. https://git-scm.com/docs/git-blame#Documentation/git-blame.txt--Cltnumgt
As long as there's less code than there was before, I'll approve it
"So then after my feature was developed, all of those unit tests didn't work any more. I deleted them."
LGTM
Had a coworker who was a bit like this. They were tasked to do one simple thing. Required a few lines of code change at most.
They end up refactoring the entire damn thing and introduced new bugs in the process.
Was there much value in the refactoring, like tech debt addressed?
Doesn't matter. One concern per PR. Refactoring and tech debt are separate concerns.
Or, if the team does allow refactoring as part of an unrelated PR, have clean commits that allow me to review what you did in logical steps.
If that's not how you worked on the change than you either rewrite the history to make it look like you did or you'll have to start over.