No post body was provided.
Django: Reformatted code with Black
91–100 of 256 posts
Re: Django: Reformatted code with Black
#92“Black” developer refused for a long time to add option to format code with single quotes with very aggressive manners. Now Django devs didn’t see that option for single quotes and code looks unpleasant.
No post body was provided.
Re: Django: Reformatted code with Black
#93Earlier 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.
> what max line width do you choose?
80
> where do you break a line if it's too long
Wherever a keyword or name ends, but does not exceed 80.
Gofmt has made opinionated decisions about everything, why stop at line breaks?
Re: Django: Reformatted code with Black
#94Shameless 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
This sounds like a living hell if you use git diff a lot to compare for small changes that might introduce a bug? which is what happens at work all the time since our unit test and CI are a joke. Not dumping on your project but the idea of that much of a change up of the code scares the dickens out of me.
Re: Django: Reformatted code with Black
#95Earlier 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.
> First, what max line width do you choose?
The whole point of an opinionated formatter is to have opinions about these sorts of things.
> Second, where do you break a line if it's too long?
It depends on the context. Yeah, writing the algorithm to make these decisions is a little complex, but it's also well-understood.
> doesn't get in your way more than necessary
What is "necessary"? It seems like you're trying to say "it makes decisions on the things I think it should make decisions on" which is fine, but it's not like choosing between `struct {` and `struct{` is objectively more critical than line wrapping.
Re: Django: Reformatted code with Black
#96A 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.
I did a blind survey of YAPF vs Black at my work. The results came back as 70% in favour of Black.
Black gives generally nicer output, and also more predictable output because its folding algorithm is simpler. YAPF uses a global optimisation which makes it make very strange decisions sometimes. Black does too, but much less often.
There are also non-style problems with YAPF. It occasionally fails to produce stable output, i.e. yapf(yapf(x)) != yapf(x). In some cases it never stabilises - flip flopping between alternatives forever!
Finally it seems to have very bad worst case performance. On some long files it takes so long that we have to exclude them from formatting. Black has no issue.
In conclusion, don't use YAPF! Black is better in almost every way!
Re: Django: Reformatted code with Black
#97Shameless 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
Very interesting, especially the method order part. I dislike the order you chose, and yet, I would be tempted to use it on my projects anyway, because being congruent is so important to me.
Re: Django: Reformatted code with Black
#98Shameless 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
This sounds like a living hell if you use git diff a lot to compare for small changes that might introduce a bug? which is what happens at work all the time since our unit test and CI are a joke. Not dumping on your project but the idea of that much of a change up of the code scares the dickens out of me.
Once the code is initially migrated (which should not break it), the diffs won't be large, since the order should be consistent.
Re: Django: Reformatted code with Black
#99A 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.
yapf is configurable, and that's why it never won.
Re: Django: Reformatted code with Black
#100Earlier quoted context omitted.
Sometimes it takes code like this: foo = ( spark .read .parquet(...) .filter(...) .withColumn(...) ) and turns it into foo = spark.read.parquet( ... ).filter( ... ).withColumn( ... ) which feels harder to parse for me. I also never quite got on board with the trailing commas.
Personally I prefer my code to read more like a sentence instead of being split up into too many lines.
I guess the point of the parent applies when the parameter lists are long, thus breaking the sentence-like appearance of the chained calls.