How to deal with long lines of code and commands in Python [closed]

Question

I've tried searching, but I couldn't find any situations similar to mine. I am writing a program and so far I've stuck to the no more than 79 characters in a line rule. However I'm not sure where to break lines in a few situations.

Here are the problem areas:

        self.proc.stdin.write('(SayText "%s")\n' % text.replace('\\', '\\\\').replace('"', '\\"'))

For this situation when I break first line after the '(SayText "%s")\n', the second line ends up being 80 characters long. Should I then break the second line somewhere in the brackets like this?

        self.proc.stdin.write('(SayText "%s")\n'
                              % text.replace('\\',
                                             '\\\\').replace('"', '\\"'))

Or would it be better to bring the entire third line to the beginning of the first brackets like this:

        self.proc.stdin.write('(SayText "%s")\n'
                              % text.replace('\\',
                              '\\\\').replace('"', '\\"'))

Another example of this is here:

        filename = tkFileDialog.askopenfilename(filetypes = (("Word list", "*.tldr"), ("All files", "*.*")))

Should I do this?

        filename = tkFileDialog.askopenfilename(filetypes = (("Word list",
                                                              "*.tldr"),
                                                             ("All files",
                                                              "*.*")))

Or this?

        filename = tkFileDialog.askopenfilename(filetypes = (("Word list",
                                                "*.tldr"),("All files", "*.*")))

What would be a good convention to follow?

Thanks.

Answer 1

In my opinion, one of the reasons to prefer shorter lines is that it makes the programmer more likely to break up code into individual shorter lines which are easier to understand and to spot errors or better ways to do things in.

from __future__ import print_function    

FMT_SAY_TEXT = '(SayText "%s")'

---

text_escaped = text.replace('\\', r'\\')
text_escaped = text_escaped.replace('"', r'\"')
text_out = FMT_SAY_TEXT % text_escaped
print(text_out, file=self.proc.stdin)

For your second example:

FILE_DIALOG_FILETYPES = (("Word list", "*.tldr"), ("All files", "*.*"))

---

filename = tkFileDialog.askopenfilename(filetypes = FILE_DIALOG_FILETYPES)

Answer 2

Whatever works for you or the conventions of the code base you are working on. PEP 8, the style guide for code included in the Python standard library, suggests that the most important consideration for continuation lines is to ensure that they are easily distinguished from indented lines (those starting a new block).

Continuation lines should align wrapped elements either vertically using
Python's implicit line joining inside parentheses, brackets and braces, or
using a hanging indent.  When using a hanging indent the following
considerations should be applied; there should be no arguments on the
first line and further indentation should be used to clearly distinguish
itself as a continuation line.

See the examples given there.

Answer 3

A convention I sometimes follow when the usual indentation style leads to too much horror, is the following:

filename = tkFileDialog.askopenfilename(
    filetypes = (("Word list", "*.tldr"),("All files", "*.*"))
)

It looks very weird at first. But it clearly lays out the "head" of the multi-line structure separately on the first line where it is prominent, and clearly shows where the multi-line structure stops. Only indenting one level, instead of to the level of the opening brace, gives you a lot more room to write the nested lines. And it has the happy side effect of causing diffs to clearly show when you only change the arguments of such a call, which is occasionally helpful.

In some ways I think this formatting convention is actually a better fit for modern high level OO languages than the usual styles, which tend to date back to C; C doesn't have chained calls and tended to have much shorter callable names due to not having objects. But since no one else uses this style I save it as a fallback for when the normal style makes readability worse.