From: Tom Fryers <61272761+TomFryers@users.noreply.github.com> Date: Thu, 15 Sep 2022 02:31:26 +0000 (+0100) Subject: Improve order of paragraphs on line splitting (#3270) X-Git-Url: https://git.madduck.net/etc/vim.git/commitdiff_plain/04bce6ad2ecf38656149fd261f01f84699cf0b6a?ds=sidebyside Improve order of paragraphs on line splitting (#3270) 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. --- diff --git a/docs/the_black_code_style/current_style.md b/docs/the_black_code_style/current_style.md index 5085b00..3db49e2 100644 --- a/docs/the_black_code_style/current_style.md +++ b/docs/the_black_code_style/current_style.md @@ -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)= _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 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 You probably noticed the peculiar default line length. _Black_ defaults to 88 characters