3 ms·
I think the only one I disagree with here is the function chains example. I may agree with a different example, but with this one I find the chained version wi
by Izkata 2y ago
I think the only one I disagree with here is the function chains example. I may agree with a different example, but with this one I find the chained version without variables much easier to understand because I'm traversing the graph visually in my head, while the variables are additional state I have to keep track of in my head.
----
Really I was hoping this would be about actual visual patterns and not syntax. It's my major issue with how strict code linting/autoformatting is nowadays.
For example, the "black" formatter for python requires this:
drawer.ellipse((10, 10, 30, 30), fill=(256, 256, 0))
drawer.ellipse((370, 10, 390, 30), fill=(256, 256, 0))
drawer.arc((20, 0, 380, 180), 15, 165, fill=(256, 256, 0), width=5)
The first argument is (x1, y1, x2, y2) of a bounding box and black wants to align x1 for "ellipse" with y1 of "arc". Do people really find that more readable than this?
drawer.ellipse( (10, 10, 30, 30), fill=(256, 256, 0) )
drawer.ellipse( (370, 10, 390, 30), fill=(256, 256, 0) )
drawer.arc( (20, 0, 380, 180), 15, 165, fill=(256, 256, 0), width=5 )
Or perhaps something more common in python, kwargs in function arguments. No spacing at all is standard python style:
Foobar.objects.create(
name=form.name,
owner=user,
location=form.location,
source=form.source,
created=time.now,
)
Instead for me it's much easier to read this, since I don't have to scan for the "=" and mentally parse each line, it's just a table:
Foobar.objects.create(
name = form.name,
owner = user,
location = form.location,
source = form.source,
created = time.now,
)
But no linters/formatters accept such spacing by default. I think flake8 (linter) could be configured to ignore whitespace like this, but black (formatter) can't.
- jraph 2y agoThere are two issues with such alignment that may make the "less readable" version a bit better despite being, indeed, arguably less readable: - a modification might lead you to realign several lines, making diffs noisier (though you can ignore white-spaces when displaying diffs, but the commits still hold these lines making navigating in the history less straightforward - we all have our own preferences wrt alignment, and your way of aligning or what you decide to align might be different from someone else, and this can lead to friction Worse is probably better here, as much as I like aligned stuff, I think black is right in this case :-)
- 12_throw_away 2y agoVertical alignments really makes me want to create a devtool stack that operates at more of an AST level and less of an "monospaced text + extra bells and whistles" level. Aligning similar expressions for ease of reading seems like exactly the sort of thing an editor should display for us without requiring some arbitrary number of spaces to be stored in a text file ...
- Izkata 2y agoAST level would have to automatically figure out what parts should be aligned, an alternative is to keep saving it in text but tweak the meaning of the "tab" character, so the developer still has control over what gets aligned: https://nick-gravgaard.com/elastic-tabstops/ https://nick-gravgaard.com/elastic-tabstops/ Not great since viewing it in something that doesn't understand elastic tabstops would just be a mess, but it solves one of the issues the other response brings up, and I think some sort of user control like that is going to remain necessary either way.
- mont_tag 2y agoWhen vertical alignment helps readability, you have use `#fmt: on/off`. Black simply doesn't have enough information to know when assignment alignment (or comment alignment) was done on purpose.