Hacker News new | ask | show | jobs
by Kinrany 1586 days ago
People conflate opinionated formats with autoformatting for some reason.

An autoformatter removes 99% effort from formatting code, and that includes code actively being worked on. Autoformatters are incredibly useful.

A standardized format removes effort spent learning to read a new format. That's an hour per format at most.

I don't see any good reasons for an autoformatter to enforce a standard. A standard would work just as well if defined as a specific configuration.

4 comments

In 30yrs of dev the truest statement in standards I can make is that they change, all the time. The 2nd truest is I and coworkers have wasted far to much energy on arguing and maintaing STDs.

Blacks value isn't autoformatter, it's preemptive discussion ender.

> Blacks value isn't autoformatter, it's preemptive discussion ender.

Exactly. I have learned that having it formatted just like I want it is FAR FAR FAR less important than having the entire ecosystem share a single format.

I am just about to embark on resolving differences in our code base due to two different clang format files being used by different teams that have now merged. Can't wait to have all those conversations and discussion over which options are correct.

One hour my ass.

Well, sorta. It's really, really mentally annoying switching between projects where standards are different. For example 80 char limit to 120 char limit takes me at least a month to fully get used to. I agree black is better than the alternative, I agree it has downsides, I'm happy some of the parameters are tunable, but I'm also glad most of them are not. I just want to write software with tools I'm used to.
Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...
Are 120 chars bad?
Maybe it's because I only have one eye and the resulting slightly reduced width of field, but wide lines drive me crazy. I need to see the whole line without scanning. This was one of python's original appeals to me...

https://pep8.org/#maximum-line-length

I can see how that would make it hard for you. I hope your team is accommodating.
I'm like her in that I have eye issues and thus can't use screens that are too large (16" absolute maximum) and even there it needs to be with large font. I wish everyone had stayed with 80 chars so I could have two vertical emacs buffers, but I've sorta gotten used to these ugly wrap around lines.

I wish people just used more locals though. I don't see what the problem is and it makes Sentry errors easier to debug.

God made the ASR-33 teletype with 80 columns for a reason.
200 chars FTW
moi
yeah, it's just too bad that black violates PEP-8.