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.
    item1,
    item2,
    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,
        long_argument1,
        long_argument2,
        long_argument3=long_default_value,
    )
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

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

ORICO — small things that stand out

More than once I've written about stuff made by Big Brand manufacturers so I decided to balance things out by writing about a mostly-unknown but good things. In short, if you need something small like HDD enclosure or some cable or USB hub or a dongle of some kind, check if ORICO makes it and chances are you won't be disappointed. It's usually slightly more expensive than low-end stuff from aliexpress but, in my opinion, it's usually worth it. Disclaimer. This post is a shameless promotion of their brand although, unfortunately, nobody paid me for it or even sent me any free stuff. Guys from ORICO and not, if you read this, I'll gladly review whatever free goodies you send me :) I only do honest reviews so better make sure to send the good stuff. At this point I own a USB hub, three different 2.5" HDD enclosures, and a precision screwdriver set from them. And probably something else I don't remember. Here are the pics: USB hub in its natural habitat

Terrible experience with bluetooth headsets and what to do about it

If you own a Bluetooth A2DP headset and any kind of personal computer, good chance is you tried connecting them together. Isn't it nice to watch movies and listen to music free from cluttering wires? Well, good chance is you hated that experience and if that was the reason for buying the headset, you might've even considered throwing it away (or using it only with your phone). Why do they suck so much? Everything points to the fact that it's not a hardware problem. The same headset most likely will work flawlessly paired with an android device or even the same computer under a different operating system (windows users report huge difference between, like, 8.0 and 8.1, and not in favor of the latter, surprisingly, I think only mac users report good stuff about their macbooks and beats although I didn't try it myself so they might all be faking it :) ). And most likely it's not even the drivers or other low-level stuff, android and desktop linux has mostly the same