You must log in or register to comment.
i have a recent diff where 300 changes are just things like moving whitespace
still fuck you for that mess
I have vim setup to trim trailing white space, I get so pissed when a small change results in a 300 line diff because of poor code hygiene.
Do ya’ll just not use linters?
in my case it is a massive legacy codebase that I don’t actually control
i get very sporadic deliveries of it and I’ve version controlled them into a jank progression
the original is in clearcase with now git on top of it and my version control is in svn
there are very shitty unresolvable reasons for all of this
but this last update was especially bad as one of their new coders is super fucking OCD and rejustifying headers and footers and fucking comments, so whitespace shit in files he is not editing code in otherwise, so that is like 300-500 files not lines
i want to break a knee cap
Linters won’t necessarily help. You also need a code formatter that screams at you if you intent badly.
I’m relatively new in my company and I’ve been hired to structurize and modernize the development. Project #1 I’m on, I’ve introduced bleeding edge things like pipelines with building, testing, etc., I’ve introduced renovate bot to keep us up to date, and I’ll introduce linting next.
They will probably kill me, but no way I’ll let them have > 2000 lines of code in one file.
Linters aren’t MVP my dude
https://github.com/axelf4/vim-strip-trailing-whitespace
There are plugins that will only trim modified lines, which resolves that issue
That’s a nice idea
Probably a bit more sophisticated than my regex solution.
I had a new dev that was tasked with changing the colors of a button. took them 3 days to do it.
when I finally got the PR there were over 300 files changed and over 100k changes.
they “fixed” the while space. I asked them who asked them to do that. “Nobody, it’s just maintenance on the codebase.”
I then had an hour long call with them reviewing everywhere they “fixed” the whitespace and got through 10% of it. I asked them if they wanted to have another call tomorrow to review the rest or if they wanted to put the changes forward they were tasked with.
they got the hint and fixed their shit.
please tell me you have an accepted code style with proper tooling and precommit hooks set up
Does the work item describe this technical cleanup? No? PR rejected for including out of scope work.
this, this is what I am dealing with, thank you for teaching him
I get it. they’re just trying to show their usefulness and skills.
I did have a talk with them after work at the bar and told them not to worry about it. the best way to show your usefulness and dedication is to do the job you were assigned to do.
there are plenty of opportunities in your career that you can use to showcase your abilities without you needing to invent them on a whim. if anything doing that will do the opposite of what you’re intending.
bright kid, just needed to be hit a couple times to see how the real world works.
rejected
“you’re welcome”
I mean, that could be extreme, or really not that bad.
Refactors have a way of generating a lot of changes. Half our job is code review, kind of have to get over it and go read some code.
If someone put the effort in to write it, it’s your responsibility to put the effort in to read it and review it.
If the style is difficult to read and non-standard for your repository or not. Conventional then your repository and your engineering team should be following set standards to ensure consistency.
If you’re doing this then most PRS shouldn’t be that difficult to review.
I say this, spending a decent part of my week reviewing something like 40+ PRs.
Ehh, it really depends. Are most of those files import changes?
I feel attacked!
