actions/black
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Improve order of paragraphs on line splitting (#3270)

Browse Source 
These two paragraphs were tucked away at the end of the section, after
the diversion on backslashes. I nearly missed the first paragraph and
opened a nonsense issue, and I think the second belongs higher up with
it too.
This commit is contained in:
Tom Fryers 2022-09-15 03:31:26 +01:00 committed by GitHub
parent e2adcd7de1
commit 04bce6ad2e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/the_black_code_style/current_style.md
View File

@ -85,6 +85,19 @@ def very_important_function(
... ...
``` ```
If a data structure literal (tuple, list, set, dict) or a line of "from" imports cannot
fit in the allotted length, it's always split into one element per line. This minimizes
diffs as well as enables readers of code to find which commit introduced a particular
entry. This also makes _Black_ compatible with
[isort](../guides/using_black_with_other_tools.md#isort) with the ready-made `black`
profile or manual configuration.
You might have noticed that closing brackets are always dedented and that a trailing
comma is always added. Such formatting produces smaller diffs; when you add or remove an
element, it's always just one line. Also, having the closing bracket dedented provides a
clear delimiter between two distinct sections of the code that otherwise share the same
indentation level (like the arguments list and the docstring in the example above).
(labels/why-no-backslashes)= (labels/why-no-backslashes)=
_Black_ prefers parentheses over backslashes, and will remove backslashes if found. _Black_ prefers parentheses over backslashes, and will remove backslashes if found.
@ -127,19 +140,6 @@ If you're reaching for backslashes, that's a clear signal that you can do better
slightly refactor your code. I hope some of the examples above show you that there are slightly refactor your code. I hope some of the examples above show you that there are
many ways in which you can do it. many ways in which you can do it.
You might have noticed that closing brackets are always dedented and that a trailing
comma is always added. Such formatting produces smaller diffs; when you add or remove an
element, it's always just one line. Also, having the closing bracket dedented provides a
clear delimiter between two distinct sections of the code that otherwise share the same
indentation level (like the arguments list and the docstring in the example above).
If a data structure literal (tuple, list, set, dict) or a line of "from" imports cannot
fit in the allotted length, it's always split into one element per line. This minimizes
diffs as well as enables readers of code to find which commit introduced a particular
entry. This also makes _Black_ compatible with
[isort](../guides/using_black_with_other_tools.md#isort) with the ready-made `black`
profile or manual configuration.
### Line length ### Line length
You probably noticed the peculiar default line length. _Black_ defaults to 88 characters You probably noticed the peculiar default line length. _Black_ defaults to 88 characters