Imperial vs Metric is a hard requirement not a convention or formatting. I have a co-worker who wants everything to be a one liner, doesn't like if/else statements, thinks exception handling is bad and will fail a code review over a variable that he feels isn't cased properly.
This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if it meets the requirements in functionality. You don't have time for that stuff, you are too busy trying to make this one person happy by turning an if else into a ternary and the end of sprint is a day away.
If a reviewer is regularly rejecting PRs because the variable names have incorrect capitalization then that's a problem with the author, not the reviewer. That is the incredibly basic shit you decide on at the start of a codebase and then follow regardless of your personal thoughts on what scheme is preferable.
If/else vs ternaries is something where consistency is a lot less important, but if you know that a team member has a strong preference for one over the other and you think it's unimportant then you should just write it how they prefer to begin with. Fight over things you think are important, not things that you think don't matter.
I worked with a guy where you would try to predict what he would bitch about next. In this example, you would write it as a ternary so you don't have to hear about it ... and he'd suggest it be an if-else statement.
Nobody fucking cares which one it is; is it readable? That's the real question. Your preference of which version of "readable" it is only applies when you are the author. If you're that picky about it, write it yourself. That's what we eventually did to that guy after the team got sick of it. Anytime he'd complain about something like that, we would invite him to write a PR to our PR, otherwise, get over it. Then, we would merge our PR before he could finish.
He eventually got fired for no longer able to keep up with his work due to constantly opening refactor PR's to the dev branch.
Sure, but if there are actual rules, agreed to and accepted by the entire team (as opposed to one guy's idiosyncratic preferences) then there should be a commit-hook to run the code through a linter and reject the commit if the rules are violated.
Yes indeed. I'm a fan of getting the team to pick an already existing lint ruleset and then doing this. You can also set to only lint changed files if you want a gradual change over in existing codebase.
This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if it meets the requirements in functionality. You don't have time for that stuff, you are too busy trying to make this one person happy by turning an if else into a ternary and the end of sprint is a day away.