Skip to content

Going black (i.e. adopting an _opinionated_ python code formatter) #324

@smoia

Description

@smoia

I was already thinking about proposing it, but then @tsalo applied it on his #219 so it's a good moment to propose it.

In the line of automating all that is automatable, there is one more thing we should adopt, a code formatter.

Code formatters are scripts that chew our code and our PRs and spit out a standardised formatted version of the code, as long as the code doesn't contain big mistakes. They shouldn't change radically the code, rather adjust it with simple rules like "always use ' instead of " for strings" or "always adopt a certain indentation rule in your scripts". "Chill" code formatters just check that a coding style is respected (e.g. autopep8 checks that pep8 is respected), while there are "opinionated" code formatters that format the code even if it respect a standard (in our case, pep8).

One (apparently) popular opinionated python code formatter is black. It's very strict and either we agree with its rules or we don't.
Another opinionated code formatter is YAPF. It's less strict, in the sense that it allows for some customisations, but it does a similar job.

There are pros and cons in adapting a code formatter.
The biggest pro: our code will always be formatted in the same way, independently from its author, so we can forget comments like "please reformat following our style" in reviews and other minutiae.
Cons: If we ask the commits to be already formatted, contributors needs to run black locally before a PR. Alternatively, if we run it during a PR merge (we need to understand how to do it smartly), the code that we will see in the repo might not be exactly the same that we wrote - although it will be very similar.

@physiopy/all, what do you think about adopting an opinionated code formatter? And what do you think about adopting black?

Outstanding questions

  1. Should we adapt an opinionated code formatter?
  2. If so, which one between black and YAPF?

PS: Labelling this urgent because we might need to wait for this before merging #219 - and we need to do that in the upcoming month. Deadline is next dev call (remember that next month it will be during the first week).

Metadata

Metadata

Assignees

Labels

DiscussionDiscussion of a concept or implementation. Need to stay always open.UrgentIf you don't know where to start, start here!

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions