It’s actually much simpler than that, what causes problems is something like this:
class Foo:
def foo = ...
def ensureA: F[A] =
...
...
...
def ensureB: F[B] =
...
...
...
def ensureC: F[C] =
...
...
...
for
a <- ensureA
b <- ensureB
c <- ensureC
yield baz(a,b,c)
def bar = ... I have trouble with eyeballing stuff like if the for is part of ensureC or directly inside of foo, or if ensureB is still inside foo or something new, or if bar is still part of foo, etc.1
So I don’t need to count braces, just glance up to see if there’s a close brace. Most of the time that’s enough. If there’s a bunch of close braces, the close brace gives me something to mouse over so the IDE can either highlight the corresponding open brace or show a tooltip with the definition it ends. A couple empty lines don’t provide either the visual cue2, or a hook for the IDE to help me out.
Counting the vertical lines doesn’t really work for me because, after about 3 lines, they start to blur together. It’s a visual processing thing, not a vision thing (sort of like dyslexia) so it’s not something that corrective lenses would fix.
Clarifications:
-
This is admittedly a bit of a contrived example, I didn’t have time to create something fully fleshed out. When I tried out the optional braces style, I found this to be most troublesome with nested functions, and most common in with files that contained nested definitions like ADTs, or when multiple implementation classes were contained in a companion object.
-
A couple empty lines won’t provide that cue after this change, they do in Scala 2 because dropping the braces only compiles if it’s a single expression. In those cases, I do prefer no braces, because I don’t need the extra context, however this no longer applies in the optional braces style.