What have you told them when they complain?

It is only one that is complaining. But he's the lead developer. I tried to find arguments in favor of mandatory code formatting, I said it is part of the QA process, it prevents people to add their own 'style' in the code so it looks more neutral and professional etc.

Why does he feel it makes code more complicated to read? Code style should be making it easier to read, because it all looks more alike. Especially in Python, which is already somewhat strict about how things ought to look and should be done.

Can you give a good reason for the mandatory code formatting? All arguments you have given so far seem to be purely aesthetic - which your developers may not find compelling.

I was suggested this link: softwareengineering.stackexchange.com/questions/189274/… - I think it gives good reasons

there are tools like "Prettier" which let you specify a code style locally and have a different one on the repo. It can even be set up without those tools. Just seems like they want to do that typical "programmer complaining for no reason" shtick

Are they complaining because they don't like the style, or are they complaining because the tool doesn't work well?

Is his problem with it just the formatting rules it applies and not the actually running of a tool? Formatting rules should be decided by the developers in the team and not a manager.

Who chose the standards that are being enforced? You by yourself, or the team that is using them?

@Brandin "It was a team decision." Was it though? OP says "we", but given that the lead developer hates it I think that "we" was more "I, and you guys better get with the program".

"What would you answer to "code formatting is totally bullshit", "it's like colors, some people like it red some other blue that's it", "it reduces my freedom", "it makes code more complicated to read with no added value" etc. ?" - if you have explained your reason for requiring code formatting and still have gotten this kind of whiny response, sometimes you have to resort to "because I said so".

What solution are you looking for here? We can't tell you whether the formatting tool is important enough for you to insist on its usage, we don't know how strongly this employees feels about this or how important they are to your team - these are all things you need to figure out yourself. Once you've done this and you've decided you'll stick with the tool, or not stick with it, and want the employee to stop complaining, or don't really care what they say, we can help with any specific question you have regarding implementing that decision.

@strawberry -It means the other developers will soon be complaining as well :-)

I thought I should mention that black is currently the No. 1 post on HN. There is quite a bit of dislike for that tool because it seems highly opinionated. There is a mention of another tool called YAPF that is supposedly more configurable. Maybe switching to that and agreeing on a set of guidelines by vote would be more agreeable to the developer in question.

Has he ever worked on a legacy app with zero consistency in code formatting? If not, maybe put him on one of those for a month or two.

You're too nice. You're doing your job by setting standards and expecting them to be followed. If it were me, I'd explain to this team member that following group standards is a vital part of his career continuation plan.,

Have you discussed whether it's code formatting in general or this specific code formatting that he's opposed to? At a glance, black seems to violate one of the key points of PEP8: consistency is only important insofar as it improves readability; when reformatting worsens readability, keep it the same. Have you asked whether that's the problem, and whether something more configurable (e.g. YAPF, as mentioned above) would be more palatable?

I can suggest a couple of things to lesson the pain. (1) Try to help him find a way to incorporate black into his editor workflow so that feedback is immediate on styling. (2) As your team migrates code to your new style, check in pure style formatting changes apart from code changes. This makes review easier until the whole code base is migrated.

Every code is formatted. It's important especially for python because as I know you have to comply to line indenting to make code blocks work. So there must be something else you understand by "code formatting" in this question. Can you give an example of the rules they find bull....?

The code formatting could be a git hook; then it does not matter if people like it or not. It happens automatically

It's like colors: I might prefer a light shade of purple to red, but I'm not going to object to traffic lights consistently using red - instead of whatever the installer fancies - on that basis. There is taste and there is signaling based on conventions.

The only reason one wouldn't like this, is that they don't like the particular formatting used. If they don't like certain formatting, then they've proven the need for a common formatting (otherwise there would more often be developers coming across formatting they don't like). Now, which formatting to use is still an issue.

@JoL: Maybe you could write an answer. I wrote half an answer covering all the personal aspects I could find but I if you know the tools you could do it better.

@Joshua Not really. I just wrote what I was seeing on HN. I've used neither black nor YAPF.

@Eigentime the main argument is that having a consistent formatter reduces the number of lines changed in between commits

@JoL: Regarding the HN thread, it looks to my eye like the great majority of posters are between somewhat and very supportive of Black. In fact, that might be a great thread for the OP to direct his problem programmer toward.

Why are you trying to impose rules on your team that your lead developer doesn't agree with?

I dislike the idea of an auto-formatter, except isort. If you need consistent style have you thought about using a linter wrapper like flake8, Prospector and/or Coala? Whilst this don't wrap a lot of the available linting tools they at least allow the developer to keep some of their style.

Can you put the complainer in charge of choosing the formatting options? Of course, with the stipulation that he cannot choose --disable-formatting or similar.

BTW when using source control unnecessary reformatting can be annoying, blame/annotation requires more steps and conflicts are more likely. You should therefore minimize reformatting to serious cases or have a dedicated sprint for it. Also it’s good to separate code change commits from mere reformatting commits for review reasons.

Tip, since you mentioned black: Suggest disabling quote normalization. Chances are good he likes single quotes (I think most Python devs do), and black prefers double quotes. With that disabled, that there might not be too many things it will change in your codebase unless it's currently a formatting mess.

@Erik The dev opposing code formatting is obviously just looking for reasons against it. How you format your code is a very personal thing.