Assignment with line continuation

Question

What is the preferred style for assigning values to variables when the variables are nested several levels deep, have fairly long names, and are being assigned fairly long values/expressions?

For example:

if this:
    if that:
        if here:
            if there:
                 big_variable['big_key']['big_value'] = another_big_variable_that_pushes_line_over_79_characters
                 other_thing = something

The character-limit breaches are only in the single digits, but I want to clean up my code so that it follows PEP 8 as faithfully as possible. I've done the following, but I am still fairly new to python, and I'm not sure if it's the sort of thing that would make an experienced Python programmer cringe:

if this:
    if that:
        if here:
            if there:
                big_variable['big_key']['big_value'] = \
                    another_big_variable_that_pushes_line_over_79_characters
                other_thing = something

I get the impression that the line continuation character is somewhat taboo; but I can't really think of a cleaner solution than the one I have if I'm working with these big dictionaries and I can't make a clean break in the middle of the variable name.

Acrefoot

Sometimes, instead of finding the convention to execute something nicely, it's better if you altogether avoid being forced to adopt a convention by removing the root of the problem. That said, if it's alright to know, why are the variable names "fairly long" in the first place? Also, "fairly long values/expressions" are alright... Unless you're repeating a fair amount of code with every expression. – Subalternate

A variable name over 79 characters is extremely suspect. Is it actually some sort of expression? – Nuggar

The variable name isn't 79 characters itself, more like 20 or 30; it just bumps the line over 79. @Nanashi The variable names are long because I'm working in Flask and leveraging Google protocol buffers where I have no control over the message or attribute names. With flask, I'm using the 'session' object and mapping the values returned by the protocol buffer messages to keys in the session, which can get pretty long, too. If I spent some time with it, I could certainly cut these names down; I was just curious if my cheap fix was that offensive to someone experienced in python. – Acrefoot

Don't worry, it's not even offensive at all. Working with Flask gives this proper context now. Your "cheap" fix is not cheap at all and if it works then it works. The overarching issue that we might be encountering here down the road is repetition -- not of variable names -- but of the fix itself. As the accepted answer pointed out, it might be a code smell, which is not always a technical mistake and most probably is a design flaw. That said, tell you what: test it out on your end. If you find yourself getting naming fatigue, then maybe it's time to look for a better hack. :) Good luck! – Subalternate

@Nanashi Alright, thanks for the help :) First code review's in two weeks, and I wanted to polish out any flagrant no-nos before I jumped in with the sharks :P – Acrefoot

In that case, throw your code to the guys at Code Review SE and watch it get mangled and reborn anew. I only asked there once about improvement of my number-to-word app and I got a massive review from one user that virtually made my simple app production-level. Granted, it's simple, but it's the backbone of a Kivy app that I'm hacking right now for my daughter's use. You'll greatly benefit there. :) – Subalternate

Answer 1

Line continuation is a bit taboo, but it is not the end of the world. We must always strive to write code such that some other programmer down the line can understand what we were doing.

Using the line continuation character \ is but one tool in our arsenal for achieving this goal of legibility.

Naming conventions are another issue. As da Vinci said "Simplicity is the ultimate sophistication." If you can make variable names small and understandable, then you are sophisticated ;-). It's too easy to just say var1, var2, var3, etc. Coming up with good names is a skill, which takes effort.

Would you rather see a variable named ChiefExecutiveOfficerOfCompanysName or CEOName?

If you can combine if statements, then your code can become even more legible. Chances are, if you have some big hierarchy of if...else-if, then you're doing something wrong (this is a code smell). For example, you might change this:

if this:
    if that:
        if here:
            if there:

Into this:

if this and that and here and there:

Or toss such gross logic into an evaluator function like so:

if EvaluateConditions(<args>):

Breaking code up into logical pieces, and putting those pieces into functions is another way to make things readable (we only have so much RAM, and we'd like to fit entire functions in it... humans aren't very good at paging)

Avoid copying and pasting code with slight changes by using parameterized functions, or some good design patterns.

Plunkett

+1: Exactly what I was thinking. Python is pretty enough to let you get away with a lot of things, but the ease-of-use shouldn't be abused to such a level that borders on unintentional obfuscation. – Subalternate

Thanks! The if hierarchy isn't this silly, obviously, and I'm having more trouble with the variable names themselves, which --as I stated in a comment above-- I don't really have control over. I was just curious if my solution was something that was used without much fuss, or if it was something that I should be incredibly wary of. – Acrefoot

Answer 2

I don't think there is any problem with line continuation in Python. But sometimes I prefer this:

big_variable['big_key']['big_value'] = (
    another_big_variable_that_pushes_line_over_79_characters
)

It is useful in long expressions, too.

Cerelly

+1. In fact, that is exactly what PEP 8 says to do: "The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation." But note that there should be spaces on both sides of the assignment operator: = (, not =(. – Shelli