Skip to main content

Settling the bracket discussion once and for all

There are quite a few ways you can format a multi-line function call/list/dictionary in a programming language. With Python (at least with PEP8) it's just two ways: hanging indentation and vertical indentation. The latter is quite straight-forward and I mention it in the notes below. The former one is what this post is about. Well, about a minor but important question of where to place the closing bracket when using it.

Yes, style is much more than formatting the commas and brackets so let's settle this and move on to the more important questions.

When using hanging indentation, the only true way is this one(*):
some_tuple = (  # Nothing here, only opening bracket.
    item3, item4,  # Several items on one line is acceptable though not recommended.
    item5,  # Last comma is important. And never, never place the closing bracket here.
)  # Again, nothing here but the bracket and it's on the same level as the opening line.
Empty line after the opening comma is mandated by PEP8 even though there are a few cases where doing otherwise would've been a possible alternative, like:
class DoNotDoThis(object):

    def just_do_not(self,
and there is a reason for that — anything after the bracket makes the opening line less visible. That's part of the reason for the two spaces before inline comment rule.

The last comma(†) and separate line for the closing bracket is important because you don't really want to see another commit in git blame just because another item was added or deleted and you had to add a comma or move the bracket. You you're using Vim, it also makes adding/deleting easier because you can operate with the whole lines (it helps with just any editor but with Vim it's more so).

I'll repeat: closing bracket should be on separate line and on the same indentation level with the beginning of the opening line (if some_tuple is indented by four spaces, closing bracket should be indented by four spaces).

It might sound like a minor issue but 1) it's the only meaningful way of doing brackets once you think about it, and 2) they should be formatted in uniform way throughout the code so why not pick this one from the three or four PEP8-compatible alternatives(‡). It's one of the things that are easily controllable with pep8 linter (or flake8 which I actually prefer, the same thing but better) — you might wanna configure some auto-check in your editor/IDE, most of them allow that easily (plus, autoindent helps tremendously).

(*) The only case when you place the closing bracket on the line with the last item is this (so-called vertical indentation):
call_some_function(argument1, argument2,
                   argument3, argument4)
Although I'm not fan of this style, it's been around since Kernighan and Ritchie... But still, don't do that, especially with long arguments. Also, while it's still acceptable to put a closing comma on a separate line when using vertical indentation, it looks kinda ugly for me.

(†) There is one case where there should be no last comma. If it's a function call/def and you're using *args or **kwargs. It's almost not worth mentioning because you don't add stuff after **kwargs and it would just result in syntax error if you placed a comma there (not sure why it was implemented that way, but that's the way things are). But still a separate line for the bracket is preferred.

(‡) The text of PEP8 is little ambiguous on this point and some variations acceptable by the letter of it are not allowed by the recent versions of the linter, but it's essentially three options for hanging indentation: a) closing bracket on the separate line on the same level of indentation as the items (doesn't work well with if/while/def blocks), b) closing bracket on the same line as the last item (makes editing harder and messes with git blame when you add/remove items), c) what I have presented above. (There is also d) bracket on any other other level of indentation, like four spaces more than for the items, but that just makes zero sense.)

Popular posts from this blog

Huawei TalkBand B2 review

Ok, so I've bought a new gadget. It was long overdue because I, being a MediaPad X1 user, sometimes feel uncomfortable pulling that monster of a phone just to check the time on answer a call. Of course, Bluetooth headsets are cheap and abundant but I don't really like the idea of keeping one in my ear all the time. And having it not in the ear usually makes it pretty much unusable. Various wearable gdgets that can show time and some notifications aren't new either, and there are a lot of cheap options, but, again, there are even cheaper watches and I don't care much about fitness tracking (I don't mind it though) and notifications (reading long texts is seldom convenient on a small screen anyway). So when I heard about the new TalkBand that combines watch and wireless headset I was all interested, read reviews, became even more interested, and waited a few weeks only because of the price and availability. The price, for most people around the world it might seem a

Russia becomes an internet outcast for some reason

It's starting to happen more and more often to me. I'm trying to use some service and all of a sudden I see an error page, sometimes a custom one but more often generated by cloudflare or a similar service, with error message effectively saying that IP addresses from Russia are banned on the service. And what is even more interesting, most of this services don't have any particular policy reasons not to allow Russian users, it's not not like they are publishing prescribed materials or doing anything interesting whatsoever. A payment processor, a popular online course provider, some random forums and information sites, one site with educational videos that I like (that one is especially funny because I'm banned from the subscription page and so can't pay them but their cdn does't care and I can actually download any video I want). But why does it happen? Is there some recommendation in some popular security guideline "block Russia, Cambodia, and Afghan