# Best practice for avoiding line break bugs in long expressions

**URL:** <https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475>\
**Category:** General Usage\
**Created:** [December 3, 2017, 12:53pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475 "2017-12-03T12:53:53Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![NickNack](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nicknack/32/1792_2.png) [@NickNack](https://discourse.julialang.org/u/NickNack)\
**Post date:** [December 3, 2017, 12:53pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/1 "2017-12-03T12:53:53Z")

</div>

I had a very frustrating debugging session yesterday. My code was running without errors but producing incorrect results. It took at least two hours for me to find this problem:

```julia
x = a + really * long +
    + (and + complex) / expression +
    - that * (spans - several)
    + lines * of / code

```

Can you spot the error? The problem is that the expression terminates after the third line because I forgot to hang a trailing `+` sign there. The fourth line evaluates without error but doesn’t do anything.

If you’re wondering why I use the convention of prefixing new lines with the operator, the reason is readability. In my opinion it is much more easy for the eyes to parse this:

```julia
10
+ 3
- 4
+ 5

```

… than this:

```julia
10 +
 3 -
 4 +
 5

```

Sadly, Julia’s line break rules encourage the latter style. As a workaround, I usually use the prefix style but add dummy `+` signs at the end of each line when the expression needs to continue.

My questions for the forum:

1. Is there a better convention for long expressions which is just as readable as my prefix style but avoids silent line break bugs? Ideally, a missed operator should produce a syntax error.
2. Would it be possible to have Julia produce a warning for “hanging expressions”, i.e. expressions that do not store results in a variable or return a value from a function?
3. Out of curiosity, why are hanging expressions allowed in the first place? Is there a use case?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [December 3, 2017, 1:04pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/2 "2017-12-03T13:04:59Z")

</div>

Your editor should indent correctly, and that can serve as a warning.

That said, the best practice is to **avoid** expressions spanning multiple lines if possible. Group calculations, and make your code more readable. The compiler won’t care, it’s job is to put it together.

---

<div class="post-metadata">

**Author:** ![dfdx](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dfdx/32/120_2.png) [@dfdx](https://discourse.julialang.org/u/dfdx)\
**Post date:** [December 3, 2017, 1:08pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/3 "2017-12-03T13:08:06Z")

</div>

> Is there a better convention for long expressions which is just as readable as my prefix style but avoids silent line break bugs? Ideally, a missed operator should produce a syntax error.

Yep:

```julia
x = (a + really * long     
     + (and + complex) / expression
     - that * (spans - several)
     + lines * of / code)

```

> Would it be possible to have Julia produce a warning for “hanging expressions”, i.e. expressions that do not store results in a variable or return a value from a function?

I don’t think so. Operators aren’t really different from functions, and functions may have side effects. So when you write:

```julia
a + b

```

depending on operand types, `+` may be a function, for example, printing its arguments to the screen or adding `b` in-place to `a`, or whatever else.

---

<div class="post-metadata">

**Author:** ![NickNack](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nicknack/32/1792_2.png) [@NickNack](https://discourse.julialang.org/u/NickNack)\
**Post date:** [December 3, 2017, 1:23pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/4 "2017-12-03T13:23:13Z")

</div>

> [@Tamas\_Papp](#):
>
> Your editor should indent correctly, and that can serve as a warning.

I just tried Sublime Text and VScode with Julia syntax. Neither of them auto-indented a multiline expression, nor de-indented a manually indented expression when a line ended with something other than an operator. Do you know of an editor that helps with this?

---

<div class="post-metadata">

**Author:** ![NickNack](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nicknack/32/1792_2.png) [@NickNack](https://discourse.julialang.org/u/NickNack)\
**Post date:** [December 3, 2017, 1:27pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/5 "2017-12-03T13:27:32Z")

</div>

> [@dfdx](#):
>
> Operators aren’t really different from functions, and functions may have side effects.

Good point. But I wonder if anyone has a practical use case for operators with side effects? After all, Julia has a very strong convention for using `exclamation!()` to warn when side effects happen in ordinary functions, so I imagine that they are quite rare in operators.

---

<div class="post-metadata">

**Author:** ![dfdx](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dfdx/32/120_2.png) [@dfdx](https://discourse.julialang.org/u/dfdx)\
**Post date:** [December 3, 2017, 2:08pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/6 "2017-12-03T14:08:44Z")

</div>

`exclamation!()` is just a convention, not a compiler requirement. Also, it’s mostly used for functions mutating state of its arguments, but there are other side effects, e.g. almost all IO functions such as `println(x)`, `write(io, x)` or `imshow(im)` clearly make side effects, but don’t use exclamation.

If you want a realistic example of operators with side effects, consider C++ style IO:

```julia
<<(io, x) = println(io, x)
io = IOBuffer()
io << "hello"

```

By the way, another pretty solution for long expressions is to split them into several like this:

```julia
x = a + really * long
x += (and + complex) / expression
x -= that * (spans - several)
x += lines * of / code

```

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [December 3, 2017, 2:49pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/7 "2017-12-03T14:49:40Z")

</div>

> [@NickNack](#):
>
> Do you know of an editor that helps with this?

I am using Emacs, with [julia-mode](https://github.com/JuliaEditorSupport/julia-emacs), and if I press `RET` after the +, the next line starts indented properly. I am pretty surprised that other editors don’t do this.

---

<div class="post-metadata">

**Author:** ![garrison](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/garrison/32/209519_2.png) [@garrison](https://discourse.julialang.org/u/garrison)\
**Post date:** [December 4, 2017, 1:24am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/8 "2017-12-04T01:24:30Z")

</div>

I always wrap multiline expressions in parentheses to avoid errors like the one you mentioned. I developed this habit after reading [PEP8](https://www.python.org/dev/peps/pep-0008/), which says

> 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.

This is also a common recommendation in Javascript style guides, as Javascript has “automatic semicolon insertion” which some people find unintuitive.

---

<div class="post-metadata">

**Author:** ![Ralph\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ralph_smith/32/10344_2.png) [@Ralph\_Smith](https://discourse.julialang.org/u/Ralph_Smith)\
**Post date:** [December 4, 2017, 2:43am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/9 "2017-12-04T02:43:08Z")

</div>

> [@dfdx](#):
>
> By the way, another pretty solution for long expressions is to split them into several like this:
> 
> x = a + really \* long  
> x += (and + complex) / expression  
> x -= that \* (spans - several)  
> x += lines \* of / code

Experiments suggest that the compiler does not (yet?) optimize this sort of construct very well for nontrivial `x`. This differs from, e.g., C++ and Fortran compilers which are designed to spend more effort on optimzation. So I beg to differ with @Tamas_Papp: the compiler does want help here.

So I vote for lots of parentheses. (Presumably that’s what Tamas means by _grouped calculations_; I’d be shocked if a Lisp aficionado like himself would suggest otherwise.)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [December 4, 2017, 8:23am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/10 "2017-12-04T08:23:58Z")

</div>

At this point, my priority is to make my code readable, and wait for the compiler to catch up. Recently I have had multiple occasions of staring at `v0.4` code that I mangled to make it a bit faster in performance-critical parts, rendering it very difficult to read. So nowadays I just write my code as I would like, and optimize the occasional critical part.

Compared to the Lisp family, Julia favors breaking up to subexpressions because assignments to new variables do not indent. Compare

```nohighlight
(let ((x something))
  (if (is-something? x)
      (let ((y (calculate-from x)))
        ...)))

```

with

```julia
x = something
if is_something(x)
    y = calculate_from(x)
    ...
end

```

so I find that my code is “flatter”.

---

<div class="post-metadata">

**Author:** ![NickNack](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nicknack/32/1792_2.png) [@NickNack](https://discourse.julialang.org/u/NickNack)\
**Post date:** [December 4, 2017, 10:55am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/11 "2017-12-04T10:55:53Z")

</div>

Thank you everyone, there are several useful suggestions in this thread. I’ll probably wrap my long expressions in parentheses from now on. Special thanks to @dfdx for disarming my gotcha questions with great examples. 🙂

---

<div class="post-metadata">

**Author:** ![flcong](https://avatars.discourse-cdn.com/v4/letter/f/da6949/32.png) [@flcong](https://discourse.julialang.org/u/flcong)\
**Post date:** [September 23, 2020, 2:13am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/12 "2020-09-23T02:13:10Z")

</div>

Took me more than an hour to figure out this bug…

---

<div class="post-metadata">

**Author:** ![ctkelley](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ctkelley/32/10684_2.png) [@ctkelley](https://discourse.julialang.org/u/ctkelley)\
**Post date:** [December 10, 2020, 12:26pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/13 "2020-12-10T12:26:13Z")

</div>

This thing just bit me. I had no idea what was happening and invested the same hour that @flcong did. I finally figured out what the deal was and then found this thread via Google. I have learned my lesson and will probably do as @Tamas_Papp suggests and write cleaner code.

---

<div class="post-metadata">

**Author:** ![PGS62](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pgs62/32/207030_2.png) [@PGS62](https://discourse.julialang.org/u/PGS62)\
**Post date:** [February 18, 2021, 9:57am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/14 "2021-02-18T09:57:26Z")

</div>

This bit me too.

A colleague had written some prototype VBA code. One monolithic function of \>500 lines ☹ and was considering porting it to C++ for better speed. I rashly suggested I port it to Julia in “a couple of hours”.

The port was easy: replace `End If` with `end`, `<>` with `!=` etc. and the Julia code ran without error first time. 28 times faster too 👍. But the results were wrong.

My first thought was to step through the code in VBA and in Julia, to see where things diverged. But I came unstuck since the debugger in VSCode kept crashing (I need to file a report). So I was back to debugging via `println` and it took me half a day to find what turned out to be a mis-translation of:

VBA:

```nohighlight
ThisNode1(i, h) = LastNode1(i - 1, h) * Pdd + LastNode1(i, h) * Pmd + LastNode1(i + 1, h) * Pud _
                  + LastNode1(i - 1, h + 1) * Pdu + LastNode1(i, h + 1) * Pmu + LastNode1(i + 1, h + 1) * Puu

```

to Julia:

```julia
thisnode1[i, h] = lastnode1[i - 1, h] * pdd + lastnode1[i, h] * pmd + lastnode1[i + 1, h] * pud
          + lastnode1[i - 1, h + 1] * pdu + lastnode1[i, h + 1] * pmu + lastnode1[i + 1, h + 1] * puu

```

VBA has an explicit line-continuation marker of space underscore `<some code> _`. I face-planted when I realised that my semi-automatic translation had simply deleted those two characters without considering whether Julia would see the current line as already complete.

Not sure if anyone would vote for adopting a line continuation marker (say space underscore) in Julia?

I like the “use brackets” suggestion by the way!

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 28, 2021, 8:50am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/15 "2021-02-28T08:50:46Z")

</div>

> [@PGS62](#):
>
> Not sure if anyone would vote for adopting a line continuation marker (say space underscore) in Julia?

If an expression is too long, I usually treat that as a code smell and refactor, or at least break it up.

In particular, there are very nice Julia packages for kernel operations like the above, eg [ImageFiltering.jl](https://juliaimages.org/ImageFiltering.jl/stable/#Linear-filtering:-noteworthy-features-1).

---

<div class="post-metadata">

**Author:** ![NiclasMattsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/niclasmattsson/32/21988_2.png) [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)\
**Post date:** [February 28, 2021, 10:51am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/16 "2021-02-28T10:51:59Z")

</div>

There are applications where long lines are hard to avoid and are certainly not code smell. This is the main water balance constraint from a JuMP model of a hydropower system:

```julia
@constraints hydromodel begin

Water_Balance[t in TIME, p in PLANT],
    Reservoir_content[t,p] ==
        Reservoir_content[shift(TIME, t-1), p] +
        + water_inflow[t,p] +
        + sum(up.flow * Water_discharge[shift(TIME, t - delay_d[up.name]), up.name, j]
                for j in LINESEGMENT, up in upstream_d[p]) + 
        + sum(up.flow * Water_spillage[shift(TIME, t - delay_s[up.name]), up.name]
                for up in upstream_s[p]) +
        - sum(Water_discharge[t,p,j] for j in LINESEGMENT) +  
        - Water_spillage[t,p]

[...]
end

```

(In the context of JuMP models we break Julia’s ordinary style conventions in favor of our own conventions more suitable for optimization modeling: e.g. Model\_variable, parameter\_name, Constraint\_name, MODELSET.)

Introducing helper variables to break this equation up would increase the size of the model. Although these helpers might be eliminated in the presolve phase of the solver they would certainly increase model generation time and memory requirements. I also think the model is easier to read when you see all the terms of the balance at once.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 28, 2021, 3:53pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/17 "2021-02-28T15:53:24Z")

</div>

> [@NiclasMattsson](#):
>
> Introducing helper variables to break this equation up would increase the size of the model.

But then you are talking about a DSL (JuMP), not Julia. I don’t know about JuMP, but Julia of course has [referential transparency](https://en.wikipedia.org/wiki/Referential_transparency) so it is not an issue.

---

<div class="post-metadata">

**Author:** ![GpuCoder](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gpucoder/32/24511_2.png) [@GpuCoder](https://discourse.julialang.org/u/GpuCoder)\
**Post date:** [July 9, 2021, 1:14pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/18 "2021-07-09T13:14:14Z")

</div>

> [@Best practice for avoiding line break bugs in long expressions](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/7):
>
> I am using Emacs, with [julia-mode](https://github.com/JuliaEditorSupport/julia-emacs), and if I press RET after the +, the next line starts indented properly. I am pretty surprised that other editors don’t do this.

VS Code does this, and has decent support for Julia Debugging, and can even run Julia in Jupyter inside a VS Code window.

Visual Studio also does this, and is generally more powerful (i.e., more programable, and a larger extension/app market), but has a larger learning curve.

---

<div class="post-metadata">

**Author:** ![blackeneth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/blackeneth/32/10353_2.png) [@blackeneth](https://discourse.julialang.org/u/blackeneth)\
**Post date:** [July 10, 2021, 7:48am UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/19 "2021-07-10T07:48:43Z")

</div>

but sometimes the formula you’re given is:

```julia
        k = 1/δ^2
        m = exp(k)
        jkur = ( 4*exp((2+2γ*δ)*k)*(2+m)
                 + 4*exp((2+6*γ*δ)*k)*(2+m)
                 + 6*exp(4*γ/δ)*(1+2*m)
                 + exp(2*k)*(-3+exp(2*k)*(3+m*(2+m)))
                 + exp((2+8γ*δ)*k)*(-3+m*(3+m*(2+m))) 
                )
                /
                (m+2*exp(2*γ/δ)+exp((1+4*γ*δ)*k)^2)

```

¯\_(ツ)\_/¯

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 12, 2021, 1:39pm UTC](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475/20 "2021-07-12T13:39:30Z")

</div>

> [@blackeneth](#):
>
> the formula you’re given is

I would break that into terms, and in any case use `LogExpFunctions.logsumexp`.

Implementing nontrivial formulas you are “given” without at least a tiny bit of investment into thinking about their numerical properties is usually a recipe for disaster, or at least preventable loss of accuracy.

[Next page](https://discourse.julialang.org/t/best-practice-for-avoiding-line-break-bugs-in-long-expressions/7475.md?page=2)