4 ms·
It's also awesome if you have to do code reviews on a laptop or don't have a massive screen available. That said, we usually just go with autoformatting via bl
by guitarbill 7y ago
It's also awesome if you have to do code reviews on a laptop or don't have a massive screen available.
That said, we usually just go with autoformatting via black, which is 120 by default. No more hassle manually formatting code to be pep8-compliant. Just have black run as a commit hook, which is super easy via pre-commit [0]. And you can run the pre-commit checks during CI to catch situations where somebody forgot to install the hooks or discovered `--no-verify`.
Can't really imagine developing Python without Black any more.
[0] https://pre-commit.com/ https://pre-commit.com/
- chimprich 7y agoI haven't got round to trying Black, but according to the project's README[0], the default is 88. Personally I think 79 is fine, but I can cope with up to about 100. Above that and you risk some really crappy code in my opinion. EDIT: Sounds like the Black author agrees. "You can also increase it, but remember that people with sight disabilities find it harder to work with line lengths exceeding 100 characters. It also adversely affects side-by-side diff review on typical screen resolutions. Long lines also make it harder to present code neatly in documentation or talk slides." [0] https://github.com/psf/black https://github.com/psf/black
- somada141 7y agoWhile initially resistant I've come around on Black for our team and a failed Black check will now make a CI build fail for all our projects. We're still using the community edition of SonarQube [0] for inspection but Black finally did away with the constant bikeshedding over formatting minutia, seems like it's saving us tons of time. [0] https://www.sonarqube.org/ https://www.sonarqube.org/