Black should have an opinion about all blank lines
See original GitHub issueIs your feature request related to a problem? Please describe.
There are a number of open issues related to handling blank lines (https://github.com/psf/black/issues/932, https://github.com/psf/black/issues/355, etc.) but I was wondering whether Black should have an opinion about all blank lines to further ensure code consistency and remove unnecessary style nits.
In addition to existing issues in relation to blank lines around comments, docstrings, etc. I wonder if Black should also be opinionated about whether blank lines should be present either preceding, within, or succeeding:
- if statements
- loops
- try/except blocks
- multiline statements
- return statements
- inline functions
- etc.
Describe the solution you’d like
Personally for if statements, loops, try/except blocks, and multiline statements I prefer having a blank line preceding and succeeding the statement if the indentation level is the same, i.e.,
try:
x = int(input())
x2 = x ** 2
y = a_multiline_statement(
x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x
)
if x % 2 == 0:
print("even")
else:
print("odd")
for i in range(x):
for j in range(x):
if i != j:
print(i * j)
except ValueError as e:
print(str(e))
Describe alternatives you’ve considered None.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:6
- Comments:6
Top GitHub Comments
Black used to initially have a strong opinion about all blank lines. My initial thinking was that if you need to split your functions into sections… you want more functions. But this argument proved to be extremely unpopular so I backed out of it.
And @ftruzzi, if you look at the history of the project, Black initially did put blank lines after control flow statements (return, raise, continue, and break). I like this myself but unfortunately there were annoying edge cases with it so it was not a good rule to enforce every time.
So in general, I think we won’t be doing what this request is suggesting. There are related bugs (like handling double blank lines in functions that are preceeded by a comment line; or standardizing on no blank lines after docstrings) that we might address. But we sadly cannot enforce any blanket usage of blank lines.
Black’s style is to put two lines between functions.