I love this except the use of the default black line length of 88. One of the things I appreciate about gofmt is being trusted with deciding on line breaks.
Django: Reformatted code with Black
81–90 of 256 posts
Re: Django: Reformatted code with Black
#82I'm so happy that languages are settling more and more on heavy reformatter usage. I'd like to think it was triggered by Go and gofmt. Working on a team where each engineer has their own personal syntax is not fun.
> Working on a team where each engineer has their own personal syntax is not fun. Why did your team not implement a style guide? Not following style is not working as a team and this needs to be addressed.
Style guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits. One of the big problems here is that people notoriously conflate “familiar” with “better” and you rarely run the counter-experiment showing that after a couple weeks everyone would be familiar with any of the serious proposals.
The advantage of a tool like Black is that it avoids that constant bikeshedding and the fact that it actually does the work for you puts the conversation in a different light because the option which is the least work is just letting Black format the code. Whatever you pick for style, you really want automatic formatting to avoid it seeming like a chore.
Re: Django: Reformatted code with Black
#83Earlier 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…
I think it's more that formatting discussion is _easy_: if you get a merge request, you can start adding comments like “this should be indented differently” or “wrap this here” and spend a lot of time “reviewing” the request without noticing that you missed an error in the logic because you were focused on the most visibly upsetting problem.
Using an automatic formatter also can help reduce diff noise, which is something I've noticed on more active projects. Using Black drives close to zero the amount of time I spend confirming that someone didn't actually change functionality along with formatting. There are other ways to get this, of course, but it's so easy just to enable Black and never spend your time on it again.
> Parentheses placement is dicated by how long words are and not by what logically belongs together, etc..
This is actually a bit more subtle: Black will remove parentheses when they don't have any effect (e.g. `(32)` will become `3 2` because it covers the entire expression) but if you use them for only a subset of the expression they'll be preserved (e.g. `(1(32))` becomes `1 * (3 * 2)`.
Re: Django: Reformatted code with Black
#84Shameless 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.
Re: Django: Reformatted code with Black
#85Earlier quoted context omitted.
+1 ...which is why I wish Black allowed more configuration. A team can often agree on a set of styles. Every team on the Python planet agreeing... now that's much harder
> A team can often agree this usually just means new team members are stuck respecting the wishes of the old-timers
Yea, but in this case the old timers have chosen Black so what's the difference?
Re: Django: Reformatted code with Black
#86I'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…
from typing import ( overload, List, etc..., ) would seem more sensible to me. I know you can make isort do that, I guess maybe not black.
My preference is actually for what GP doesn't like; the reason I don't like your suggestion is that:
from typing import (
overload,
)
-from typing import overload
+from typing import (
+ overload,
+ List,
+)
+ List,Re: Django: Reformatted code with Black
#87Every 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.
Does the user matter? As long as the commit message is something sensible like 'Autoformat with black' it can be easily ignored when seen, and you can avoid seeing it with blame as simonw suggests.
Re: Django: Reformatted code with Black
#88Why is it impossible to rebase? I didn’t understand the conversation around merging and rebasing
Re: Django: Reformatted code with Black
#89The 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.
With a style guide and linter I've never experienced this and idk why you would. Then the only time style comments come up is pointing someone to the guide
Re: Django: Reformatted code with Black
#90A little shoutout to a alternative Python formating tool https://github.com/google/yapf (developed by Google).
The built in "facebook style" formating felt by far the most natural to me with the out of the box settings and no extra config.