> Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I hear this all the

> Because black frees us of any argument over coding style in merge requests and this is great. It helps us focus on the important things. I hear this all the time, along with 'Juniors will be confused' but it never seems reasonable. Sometimes I line up variables: name_field_id = 0x01 address_field_id = 0x02 Sometimes I don't. I do it when the cognitive load is more on the values or the identifiers, as a group. No tool is going to help with this judgement call. Sometimes stuffing a method on one line is best because you get ten boilerplate methods on ten lines and can see the similarity, other times that's just silly and they'd be best spaced normally. Sometimes I use a rightward assignment { ... } => x because it fits the code better, leaving the reference to x right next to the next statement which will use it. > so we regularly argue over them and this is a waste of time. Strange disfunction. It sounds like your team is too opinionated to allow other opinions. > I wish it were much more opinionated Suggest turning on more rules but leaving them as suggestions. Where any reason to not follow them is enough. You do want to make sure people have some reason to make sure they aren't just leaving a mess but it's easier to get them to care about style if they have a say in what clean looks like. As an aside, part of the issue is comfort with the tooling. If I have to work in someone else's file and I hate the syntax and it's a big deal, I first run the linter to make the code look my way, make the change, run the linter to go back to their style, squash it onto my change, and rebase away the first lint. Work done, no problems dealing with someone else's style - even in the case that it would otherwise be a problem. I never have to, but because I can it doesn't bug me.