Hacker News new | past | comments | ask | show | jobs | submit login

> and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019

I don't know why 80 characters is a problem. I don't use the linter but I enforce this rule religiously with a couple of exceptions (long strings comes to mind). It forces me to think heavily about the structure of the code I'm writing. If I'm nesting so deeply, something has gone wrong. If I've got a ton of chained methods or really lengthy variables, it forces me to rethink them.

This also has the advantage of being able to put 4 files next to each other with full visibility. Vertical space is infinite, horizontal space isn't. It's probably a good idea to use it.

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/

I 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

While 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/

All I know is that with 80-char width I can have 2 files side-by-side on a 15" MBP along with the dir-tree on the left in an editor like PyCharm or VSCode and fully see both files wo wrapping. It helps my productivity immensely.

Same deal when it comes to reviewing PRs in GitHub. Wrapping just interrupts flow for me.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact