The 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.
No post body was provided.
Django: Reformatted code with Black
71–80 of 256 posts
Re: Django: Reformatted code with Black
#72Earlier quoted context omitted.
I guess the closing parens irk me the most e.g. assert outputs.get("foo.bar.baz", "default") == pytest.approx( time_recorder.time_taken, abs=0.0001 ) I get why it's done that, but I just don't think it helps humans read. Part of the twisted beauty of PEP-008's narrow lines is that you're forced to extract (named) variables, or avoid overly indented code by extracting methods or applying higher level abstractions. In…
I tend to prefer the trailing paren on the following line. I'm not sure if there's a principled reason it helps (or hurts), but stuff like: assert outputs.get("foo.bar.baz", "default") == pytest.approx( time_recorder.time_taken, abs=0.0001) always feels a bit off and "unbalanced" to me. The opening paren doesn't have anything immediately following it, so it feels 'symmetric' that the closing paren shouldn't have anyt…
I agree with it feeling unbalanced. I don't register that statement as being complete. Putting the parenthesis on its own line is the same as putting a closing curly brace on its own line in languages that use those.
int foo() {
return 1; }
Maybe it could be broken up differently though to avoid the lone paren.
assert (outputs.get("foo.bar.baz", "default") ==
pytest.approx(time_recorder.time_taken, abs=0.0001))Re: Django: Reformatted code with Black
#73Earlier 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…
Those discussions, indeed, are pointless.
They are also huge timesinks, people spend less time sometimes deciding which framework or language or cloud provider to use and which country to register their company in, than spending hours and hours on how some SICK ANIMAL forgot a trailing comma somewhere, or bikeshedding how many spaces to indent with, and who uses an ultrawide monitor and wants wide columns (but then again someone turns theirs into portrait mode, and wants narrow columns), etc. Gobs and gobs of time, totally disproportionate to the issue at hand!
Yes, black sometimes produces fugly code, but at least the bikeshedding can fucking stop. There are bugs to fix, for chrissake. Yes, some people are not thoughtful enough to format their code like a piece of poetry, so what? Should everyone take Typography 101?
There is also a huge cohort of programmers who, when doing reviews and finding nothing to nitpick, resort to criticizing, in great detail, the code formatting of pull requests. They fell they MUST leave some critique or else their review is incomplete and their peepee is small. I find it hugely enjoyable that a tool like black can deprive them of the joy of belittling someone else for microscopically minor things and concentrate on, say, the actual merit of a change.
Re: Django: Reformatted code with Black
#74What'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?
Re: Django: Reformatted code with Black
#75Earlier quoted context omitted.
Indeed, I don't like Black's style, but I prefer working in a Black codebase than one where everyone has their own preference. Having style guidelines in a team is also a great way to remove pointless debates when reviewing PRs.
+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
The etymology of black is "any color you like, as long as it's black" [0]. The whole point is that it's _not_ configurable.
Re: Django: Reformatted code with Black
#76Earlier quoted context omitted.
It's odd that nobody followed Go's formatter in letting developers break lines themselves and mostly fixing indentation and spacing. I thought they made good choices.
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.
Re: Django: Reformatted code with Black
#77What'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. Ensures that anything merged to master keeps the formatting conventions established in the project.
Re: Django: Reformatted code with Black
#78What'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?
The former, in my case. Last thing I want is someone merging their own "creative interpretation" of proper formatting.
Re: Django: Reformatted code with Black
#79What'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
Re: Django: Reformatted code with Black
#80I'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.
On this particular small team, there was no style guide, and nobody could agree on what would go in it. It was dysfunctional.