I am so sorry, but what is Black? I use django but I have never heard of Black
Django: Reformatted code with Black
151–160 of 256 posts
Re: Django: Reformatted code with Black
#152The output does look better but this also just looks like every PR for applying a linter / formatter I've ever seen. Not sure why this is news worthy.
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.
By chaining yourself to a format preferred by a machine, you free yourself of having to understand how and why another human thinks the way they do and prefers what they prefer.
Simply give up your mind and you too can be free.
Re: Django: Reformatted code with Black
#153Reading 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.
Re: Django: Reformatted code with Black
#154Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits. 0: https://github.com/bwhmather/ssort
Does it put high-level business logic at the top or the implementation details at the top? Which is preferable, and why?
Implementation details at the top. Python is a scripting language so modules are actually evaluated from top to bottom. Putting high level logic up top is nice when you just have functions, which defer lookup until they are called, but you quickly run into places (decorators, base classes) where it doesn't work and then you have to switch. Better to use the same convention everywhere. You quickly get used to reading a module from bottom to top.
Re: Django: Reformatted code with Black
#155Reading 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.
You brilliant lunatic
Re: Django: Reformatted code with Black
#156Earlier quoted context omitted.
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 wor…
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...
Re: Django: Reformatted code with Black
#157I've been using black at work for over a year now. I don't much care for some of the choices it makes, which can sometimes be quite ugly, but I've grown used to it and can (nearly) always anticipate how it will format code. One nice side effect of encouraging its use is how, at least where I work, it was very common to use the line continuation operator \ instead of encompassing an expression in parentheses. I always…
At least it doesn’t have a dishonest name such as Prettier, which turns perfectly good looking code into digital vomit.
Re: Django: Reformatted code with Black
#158Every 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.
You can tell "git blame" to ignore specific commits which helps a lot here: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...
This is a nice feature, but I do wish that .git-blame-ignore-revs was automatically applied, similarly to .gitignore and .gitattributes. Hopefully there are plans to do so in a future Git release?
Re: Django: Reformatted code with Black
#159Reading 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've been thinking about this for a while too.
I think that making editors do this is within the realms of feasibility. Most support auto-formatting to your preferred style so it doesn't feel like a leap for it to format to your preferred style but keep the file on disk the project owner's preferred style. I haven't looked extensively to see if this already exists though but we chatted about this at work as I was advocating for use of prettier on a front-end project!
Re: Django: Reformatted code with Black
#160Earlier quoted context omitted.
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?