How to work with long lines of code and commands in Python

Question

I tried to search, but I could not find situations like mine. I am writing a program, and so far I have adhered to no more than 79 characters in a linear rule. However, I'm not sure where to break the lines in several situations.

Here are the problem areas:

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

In this situation, when I break the first line after "(SayText"% s ") \ n ', the second line ends with a length of 80 characters. Should I then split the second line somewhere in brackets like this?

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

Or it would be better to move the entire third line to the beginning of the first brackets, such as:

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

Another example of this:

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

Should I do this?

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

Or that?

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

What will be a good agreement?

Thanks.

Answer 1

In my opinion, one of the reasons for the preference for shorter lines is that it makes the programmer more likely to break the code into separate shorter lines, which are easier to understand and identify errors or improve ways to do something.

 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

As a rule, I try to break the first point in the "dominant" syntactic connective and use one indentation for the continuation line for the normal operator, or double indentation if the polyline is followed by a colon. However, if the syntax is "." then I prefer to use temporary variables, as this is usually more clear.

For your examples:

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

I would write:

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

For

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

I would write:

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

For function calls with many arguments, I sometimes find it most clear to put one on a line, even if more can fit. For instance.

 filename = some_function_call_with_long_args( the_first_argument = some_rather_long_expression, another_argument = some_other_expression ) 

It would be:

 filename = some_function_call_with_long_args( the_first_argument = some_rather_long_expression, another_argument = some_other_expression ) 

or even:

 filename = some_function_call_with_long_args( the_first_argument = some_rather_long_expression, another_argument = some_other_expression ) 

A variant of this is shown for statements with final completion:

 for foo in this_is_a_long_function_generating_an_iterable( here_are_some = arguments, and_they = are_long_too ): print foo 

becomes:

 for foo in this_is_a_long_function_generating_an_iterable( here_are_some = arguments, and_they = are_long_too ): print foo 

but usually it will be clearer

 foo_iter = this_is_a_long_function_generating_an_iterable( here_are_some = arguments, and_they = are_long_too ) for foo in foo_iter: print foo 

or

 foo_iter = this_is_a_long_function_generating_an_iterable( here_are_some = arguments, and_they = are_long_too ) for foo in foo_iter: print foo 

One final note: some people find these rules obsolete since you can usually use a larger window. I believe that these rules are very useful because:

• with successively short lines, I can see the code in more open windows (or more editing panels)
• the method above shows the logical structure of the program
• when it is not easy to break the lines, this is often a sign that the structure will be better displayed with temporary variables (etc.).

Answer 3

Regardless of what works for you or for the conventions of the code base you are working on. PEP 8, a 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 indentation (starting with a new block).

 Continuation lines should align wrapped elements either vertically using Python 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 examples here.

Answer 4

The convention that I sometimes follow when the usual indentation style is too horrifying is this:

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

At first it looks very strange. But he clearly sets out the "head" of the multi-line structure separately on the first line, where it is visible, and clearly shows where the multi-line structure stops. Only indentation at the same level, and not to the level of opening the parenthesis, gives you much more space for writing nested lines. And it has a happy side effect that gives a difference to show clearly when you only change the arguments of such a call, which is sometimes useful.

In a sense, I believe that this formatting convention is actually better suited for modern high-level OO languages ​​than the usual styles, which tend to relate to C; C does not have chain calls and tends to have much shorter called names due to the lack of objects. But since no one else uses this style, I save it as a reserve when a normal style makes readability worse.

Answer 5

The best place to look for general Python code formatting rules is pep8 . There are “rules” for how / when to break longer lines of code.

However, for your specific examples, I usually assign the arguments to the variables in the previous line:

 msg = '(Say Text "%s")\n' % text.replace('\\', '\\\\').replace('"', '\\"') self.proc.stdin.write(msg) files_types = (("Word list", "*.tldr"), ("All files", "*.*")) filename = tkFileDialog.askopenfilename(filetypes=file_types) 

Answer 6

I don’t think that many people still use the VT100 , so you can safely raise it to 100/120 characters.

For something like your first example, it is much easier to read when you break 4 operations into 2 lines of 2:

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

Example 2:

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

Answer 7

These are your preferences.

When I code, I prefer to break it down with an argument if necessary. Of course, you can do something differently. That is all you think.