Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django: Reformatted code with Black

github.com

Post reply on HN
Print view View original

171–180 of 256 posts

Re: Django: Reformatted code with Black

#171

Post by neamar »

yawaramin wrote: post #128
throwaway894345 wrote: post #59

Earlier quoted context omitted.

> oesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code This is fine with me--I think it makes sense to optimize for readability, and I can read a long vertical list of arguments a lot more readily than a long comma-delineated…

> the default width should be at least 120 characters, I mean we're in 2022 after all Even in 2022, some people don't have wide external monitors, sometimes like to view two files (or a diff) side-by-side, or need to use GitHub/BitBucket/etc. code viewer pages. Also, it's still difficult for humans to read long lines.

True, but we also have word wrap to deal with this automatically!

Re: Django: Reformatted code with Black

#172

Post by BiteCode_dev »

eredengrin wrote: post #146
BiteCode_dev wrote: post #115

Earlier quoted context omitted.

There is no "best format". It's a matter of opinion. Taste is something we cannot objectively agree, and in fact, people will end up arguing even about this very statement, offering what they think is an objective measure. Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration. To be redone for each project, team, etc. Worse even in FOSS where everybody will come in a tic…

> Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration Sounds like a team problem, I've been on plenty of teams that use clang-format for c/c++ and there have never been any issues like this. Team players know that (almost all) arguing over formatting is not a good use of time. (edit: in case not clear, clang-format is extremely configurable. Set a default config and li…

> Sounds like a team problem,

You had a good team. I had a great mum. Some people have great doctors.

> It just shifts from "let's change this flag in yapf" to "let's switch to yapf because black looks ugly and gives us no options".

If the practice doesn't match the theory, I'd rather trust the practice.

Re: Django: Reformatted code with Black

#173

Post by whalesalad »

VBprogrammer wrote: post #153

Reading some of the comments here it's become clear to me that the next stage in the development of auto-formatters is to have the formatter commit the code as a canonical format but to display the code to each individual contributor in the style of their choosing. Thus removing all kinds of arguments about whether 80 or 120 columns is the one true width.

I think this is the most wonderful part of Lisp. Specifically its homoiconicity, or the fact that the syntax of the program is the program, and yet the syntax (as far as linebreaks, indentation, spaces vs tabs, etc) is completely irrelevant to the meaning of the code.

Ostensibly you could craft a future where what is on disk is not what the user is actually editing - a-la the virtual DOM. And on read/save the developer's preference is used to transform the syntax into their ideal shape. This is trivial in a Lisp, but not so easy in other languages.

Re: Django: Reformatted code with Black

#175

Post by timhh »

wyuenho wrote: post #23

Every time I was tempted to do something like this, I hesitated because I didn't want every other line in every file with my name on a single commit, mostly to avoid making git blame harder than necessary. It would be nice if there was a kind of diffing algorithm that can diff code units *syntactically* across history.

In my experience it's better to just bite the bullet and do it. Eventually you will do it, so you either screw up git blame for a small codebase with a small amount of history, or wait until it is a large codebase with a large amount of history to screw up.

> It would be nice if there was a kind of diffing algorithm that can diff code units syntactically across history.

There have been quite a few attempts at that though I've only seen them applied to resolving merge conflicts. It would be interesting to try them for blame too.

Re: Django: Reformatted code with Black

#176

Post by BeetleB »

eredengrin wrote: post #146
BiteCode_dev wrote: post #115

Earlier quoted context omitted.

There is no "best format". It's a matter of opinion. Taste is something we cannot objectively agree, and in fact, people will end up arguing even about this very statement, offering what they think is an objective measure. Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration. To be redone for each project, team, etc. Worse even in FOSS where everybody will come in a tic…

> Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration Sounds like a team problem, I've been on plenty of teams that use clang-format for c/c++ and there have never been any issues like this. Team players know that (almost all) arguing over formatting is not a good use of time. (edit: in case not clear, clang-format is extremely configurable. Set a default config and li…

All problems are team problems. It's OK to use technical solutions to get around them.

Re: Django: Reformatted code with Black

#177

Post by eternauta3k »

whalesalad wrote: post #173
VBprogrammer wrote: post #153

Reading some of the comments here it's become clear to me that the next stage in the development of auto-formatters is to have the formatter commit the code as a canonical format but to display the code to each individual contributor in the style of their choosing. Thus removing all kinds of arguments about whether 80 or 120 columns is the one true width.

I think this is the most wonderful part of Lisp. Specifically its homoiconicity, or the fact that the syntax of the program is the program, and yet the syntax (as far as linebreaks, indentation, spaces vs tabs, etc) is completely irrelevant to the meaning of the code. Ostensibly you could craft a future where what is on disk is not what the user is actually editing - a-la the virtual DOM. And on read/save the develop…

Indentation is not the reason why it's hard to autoformat Python code, or any other language for that matter.

Re: Django: Reformatted code with Black

#178

Post by skybrian »

rob74 wrote: post #76
throwaway894345 wrote: post #66

Earlier quoted context omitted.

Honestly the only grievance I have with Go's formatter is that it doesn't automatically break lines. I'd be a big fan of "if two programs parse to the same AST, they should format the same" and if that's too aggressive perhaps allow for `// go:nofmt` annotations or something. In whatever case, `gofmt` gets at least 95% right.

Nah, I can totally understand why they decided to stay away from this can of worms. First, what max line width do you choose? Second, where do you break a line if it's too long? I think gofmt gets the balance exactly right: makes source code easier to read by providing a unified formatting style, but doesn't get in your way more than necessary.

I believe one reason they chose it is so that automatic reformats like renaming a variable don't cause reformats to more lines than necessary.

Keeping lines reasonably short is nice but doesn't need to be done strictly. It can wait until someone edits the code.

Re: Django: Reformatted code with Black

#180

Post by 0xJRS »

crad wrote: post #107
declnz wrote: post #13

Aside: I love a good linter, but as a long-time Python fan I find it sad that Black has so little configuration (yes, I know, but still) and moreover that it often produces code that no human Python dev I know would write... Python was always meant to look concise / beautiful... (MyPy has also made this trickier too)

I'll take yapf --style=pep8 formatting over black any day.

Having gone through the effort of testing yapf and black a few years back I also prefer yapf.
Post reply on HN