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

191–200 of 256 posts

Re: Django: Reformatted code with Black

#191

Post by wyuenho »

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'm pretty sure you can already do that with some scripting. Just write a git alias, say git edit, which will run the work tree copy through your favorite formatter to a temp file and send that temp file to your editor, and a commit hook to rename all the temp files back to the original and format them back to whatever the canonical format is. You can also configure your git diff and stash etc to make them aware of the temp file naming convention. You might even be able to write a script to generate all these aliases. There are some annoying details such as needing a separate command to temporarily move the temp files to the work tree to give your IDE a hand, but totally doable. It's going to take maybe a few weeks of work, but doable for a single person.

Re: Django: Reformatted code with Black

#192

Post by mkesper »

bckr wrote: post #79
umvi wrote: post #74

What's the point of putting linters into CI? Is the point to fail the build if the code wasn't pre-formatted with i.e. Black? Or is the point to autoformat and autocommit the formatted code?

> Is the point to fail the build if the code wasn't pre-formatted with i.e. Black? It's this one > Or is the point to autoformat This one is done with pre-commit (which should probably be named pre-push?) hooks > and autocommit the formatted code? I don't think this one is done, and I think it's undesirable

Pre-commit hooks really happen when you type 'git commit'. If you have failing checks in them, your commit will be aborted.

Re: Django: Reformatted code with Black

#193

Post by zmmmmm »

captainmuon wrote: post #48
owaislone wrote: post #10

Earlier quoted context omitted.

Using black is not about how the code looks but to eliminate an entire suite of review comments/discussions. Everyone simply runs black over all code before submitting and no one ever comments about how anything is formatted.

Naive question, but why is everybody so aggravated by formatting discussions? It seems to be a widespread opinion that these discussions are just 1) pointless and 2) difficult and time consuming. My personal experience is that 1) in many cases you do benefit from taking a moment, going through your code and thinking about presentation. And 2) I find it not at all difficult to settle. A change either doesn't matter, t…

Like you, I'm quite fascinated by the apparent massive frustration and time sink that is apparently happening due to formatting discussions. Been working nearly 25 years in software at all levels, rarely using auto-formatted code, literally can't remember having one of these discussions. If anything I might even say I wish people cared a little more.

I do quite often artisanally craft formatting of specific code sections to highlight the intent of the algorithm or design. I assume black would merrily destroy all my hard work.

Re: Django: Reformatted code with Black

#194

Post by williamvds »

michaelbarton wrote: post #163
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 that’s already possible using git smudge. Example here: https://bignerdranch.com/blog/git-smudge-and-clean-filters-m...

Smudge & clean might do the trick, but it could be dirty. The smudge -> clean process might produce additional changes that aren't related to the purpose of your commit. Whitespace in particular could be a problem, especially where there's ambiguity in how it should be used. black isn't as bad because it has stricter rules on whitespace. Still, if you aren't checking style rules before every merge someone using smudge and clean could end up reformatting entire files.

IMO the next next step is, as others have discussed on HN, getting your version control to store and abstract syntax tree. tree-sitter could make this easier nowadays, but I think it'd need more invasive changes in Git than just using the filters.

See this HN thread https://news.ycombinator.com/item?id=28670372

Re: Django: Reformatted code with Black

#196

Post by crad »

stavros wrote: post #133
crad wrote: post #113

Earlier quoted context omitted.

What's wrong with configurable? Too much opportunity to bikeshed? I figured yapf was not "new" which is why black won. Starting about 5-6 years ago there was a push in the Python community to replace solved problems with new ones in what appears to me as chasing the JavaScript community. Instead of consolidating on existing tools that worked well but had some rough edges to smooth out, numerous projects came about to…

> Too much opportunity to bikeshed? Yes, and also too hard to set up. It's extremely dumb, but I'm much more likely to use something I can't configure, because if I can configure it, I'm going to want to , and it'll take forever to make all those choices.

I've never had to configure yapf, even though I could...

"yapf -i --style=pep8" works great.

Re: Django: Reformatted code with Black

#197

Post by barbazoo »

jessaustin wrote: post #167
barbazoo wrote: post #160

Earlier quoted context omitted.

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.

Re: Django: Reformatted code with Black

#198

Post by NAHWheatCracker »

I suggested Black to a team I was on a year ago and one developer hemmed and hawed about how he likes to format arrays or something. I didn't win any friends by pointing out that disregarding those personal preferences is part of why I was recommending it.

A year later and it seems to be the default on all projects I'm working on and I'm loving it.

Re: Django: Reformatted code with Black

#199

Post by Spiritus »

jreese wrote: post #183
ziml77 wrote: post #64

Earlier quoted context omitted.

Try isort instead https://github.com/PyCQA/isort

Give µsort a try instead; it's focused on providing more safety when applying sorting to large codebases, and is designed to pair well with black out of the box: https://usort.readthedocs.io https://ufmt.omnilib.dev

For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.

Re: Django: Reformatted code with Black

#200

Post by sockpuppet69 »

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…

No post body was provided.
Post reply on HN