search

bionitio-team / bionitio-python

Demonstrating best practices for bioinformatics command line tools
MIT License
26 stars 12 forks source link

Suggestion: Use Black code formatter #6

Open ewels opened 4 years ago

ewels commented 4 years ago

Python Black is a package that formats Python code in a very strict manner.

Whilst it can be used to check code (eg. for CI tests) the main idea is that it reformats files in place. Most code editors have plugins that can run Black every time the developer hits Save, or it can be set up as a pre-commit hook for git.

Black is becoming increasingly common in the Python community. I heard in the BOSC talk by @peterjc that @biopython now uses it (see discussion) and we started using it for nf-core/tools just recently.

Black makes Python project code hyper consistent, which is great for community projects. Introducing Black at a later date does clobber the git history though, so if possible setting it up at the start of the project is ideal.

If it seems like a good idea, it's quite easy to set up. You just need:

peterjc commented 4 years ago

Glad the talk was of interest. You might also want to include black checks in your git pre-commit hook (ideally run on the developer's machine), and your continuous integration (TravisCI, along side another automated style or linting checks) to enforce this.

claresloggett commented 4 years ago

I'm definitely in favour

multimeric commented 4 years ago

The tricky question here, though, is that if we're using Black for Python, then we're treating it as a "best practise", which honestly it probably is. But then what about other languages? prettier helps with JS, but what about the majority of other languages that don't have an auto formatter? Is it a reasonable best practise if most languages can't implement it?

ewels commented 4 years ago

How about using Coala? https://coala.io/

I haven’t used it personally yet but that has support for a lot of languages.

claresloggett commented 4 years ago

I think best practice varies by language. In languages where there is no tool or language feature to do something, that thing becomes kind of theoretical best practice which can't be (easily) implemented and we can't demonstrate. I don't think it should inhibit us from implementing language-by-language best practice. One purpose of bionitio is to allow comparison across implementations, but another very important purpose is to give people an appropriate starting point for their own project.