+### Empty lines
+
+*Black* avoids spurious vertical whitespace. This is in the spirit of
+PEP 8 which says that in-function vertical whitespace should only be
+used sparingly. One exception is control flow statements: *Black* will
+always emit an extra empty line after ``return``, ``raise``, ``break``,
+``continue``, and ``yield``. This is to make changes in control flow
+more prominent to readers of your code.
+
+*Black* will allow single empty lines inside functions, and single and
+double empty lines on module level left by the original editors, except
+when they're within parenthesized expressions. Since such expressions
+are always reformatted to fit minimal space, this whitespace is lost.
+
+It will also insert proper spacing before and after function definitions.
+It's one line before and after inner functions and two lines before and
+after module-level functions. *Black* will put those empty lines also
+between the function definition and any standalone comments that
+immediately precede the given function. If you want to comment on the
+entire function, use a docstring or put a leading comment in the function
+body.
+
+
+### Trailing commas
+
+*Black* will add trailing commas to expressions that are split
+by comma where each element is on its own line. This includes function
+signatures.
+
+Unnecessary trailing commas are removed if an expression fits in one
+line. This makes it 1% more likely that your line won't exceed the
+allotted line length limit. Moreover, in this scenario, if you added
+another argument to your call, you'd probably fit it in the same line
+anyway. That doesn't make diffs any larger.
+
+One exception to removing trailing commas is tuple expressions with
+just one element. In this case *Black* won't touch the single trailing
+comma as this would unexpectedly change the underlying data type. Note
+that this is also the case when commas are used while indexing. This is
+a tuple in disguise: ```numpy_array[3, ]```.
+
+One exception to adding trailing commas is function signatures
+containing `*`, `*args`, or `**kwargs`. In this case a trailing comma
+is only safe to use on Python 3.6. *Black* will detect if your file is
+already 3.6+ only and use trailing commas in this situation. If you
+wonder how it knows, it looks for f-strings and existing use of trailing
+commas in function signatures that have stars in them. In other words,
+if you'd like a trailing comma in this situation and *Black* didn't
+recognize it was safe to do so, put it there manually and *Black* will
+keep it.
+
+### Strings
+
+*Black* prefers double quotes (`"` and `"""`) over single quotes (`'`
+and `'''`). It will replace the latter with the former as long as it
+does not result in more backslash escapes than before.
+
+The main reason to standardize on a single form of quotes is aesthetics.
+Having one kind of quotes everywhere reduces reader distraction.
+It will also enable a future version of *Black* to merge consecutive
+string literals that ended up on the same line (see
+[#26](https://github.com/ambv/black/issues/26) for details).
+
+Why settle on double quotes? They anticipate apostrophes in English
+text. They match the docstring standard described in PEP 257. An
+empty string in double quotes (`""`) is impossible to confuse with
+a one double-quote regardless of fonts and syntax highlighting used.
+On top of this, double quotes for strings are consistent with C which
+Python interacts a lot with.
+
+On certain keyboard layouts like US English, typing single quotes is
+a bit easier than double quotes. The latter requires use of the Shift
+key. My recommendation here is to keep using whatever is faster to type
+and let *Black* handle the transformation.
+
+
+## Editor integration
+
+### Emacs
+
+Use [proofit404/blacken](https://github.com/proofit404/blacken).
+
projects / etc / vim.git / blobdiff