Another handy tool is an editor with rainbow delimiters. This feature changes the colour of each matched pair of parentheses so that they can be seen at a glance.

There's really no excuse not to, since refactoring functional code tends to be as simple as taking a node in a tree and moving it out.

In Java, if you have a class containing a function which itself contains an if-statement containing multiple lines. You will have three lines at the end of the file containing nothing but }. There is no reason you couldn't clump those together and thus end the last statement in your function with }}}.

The difference is, in Java it's good practise to give each } a seperate line. In Lisp, most people prefer to clump their ) together.

Also, you could easily end a function with alot of )))))).

(defn unique-large-squares [list-of-nums] (count (unique (filter #(> % 100) (map #(* % %) list-of-nums)))))

Of course, if the clump of ) are off-putting, you could always use ->

(defn unique-large-squares [list-of-nums] (-> list-of-nums (map #(* % %)) (filter #(> % 100)) (unique) (count)))

`)))))` at the end of a function doesn't matter. The function's over. Even if you needed to make a change that would break the clump up, you generally navigate it from the opening side.

But if it's at the end of a fat true-expression of an if-statement, you probably have to add a `;; x is false` comment to remind yourself what's going on by the time you get to the false-expression.

Just like in Python when you get to an `else:` yet you have to scroll up just to find the matching `if` because somebody decided to roll their own SOAP client on the true path.

Aside from the fact that if you're color blind then apparently you're stuck with all the )))))))s.

I personally hate the opening { stuck on the end of the line in C/Java. For me it goes on a line on its own pretty much every time.

I've lost count of the amount of times there's been a subtle bug introduced by incorrect scope as a result of a { being missed from the end of a line and not being noticed due to the code being formatted as if it was there.

With a { sat on its own, directly lining up with the }, that's pretty much impossible to miss.

Hopefully the formatting will work for this -

For example,

    if (isOK)
        for(thing in list
        {
            doSomething(thing);
        }

    }

whereas

    if (isOK)
        for(thing in list){
            doSomething(thing);
        }
    }

As for closing braces, I associate them with the start of the statement itself (the if and for) and not the opening brace, assuming the indentation is consistent.

I'm not arguing one is necessarily more right than the other - just that I prefer the way considered less right by consensus.

The argument about taking up less space, I get - although given the massive monitors that we all have these days, that seems far less of a consideration than when I used to work on 20-line terminals.

What I just genuinely struggle to understand is how it's clearer (and if I managed to understand, it might help me parse other peoples' code).

Let me turn my code into something that actually has a matching amount of braces

    while (readLine){
        if (isOK)
            loadSomething();
            for(thing in list){
                doSomething(thing);
        }
    }

    while(readLine)
    {
        if (isOK)
            loadSomething();
            for(thing in list)
            {
                doSomething(thing);
        }
    }

With second one, even the most rudamentary scan tells me that there's an opening and a closing brace that don't match up. All I have to do is scroll up and see whether there's a matching { at the same indentation.

I'm not saying you're wrong - if you are, most people who write coding articles, or code that I have to look at, are also wrong. But I would love to know what it is that other people can see easier/quicker in the first code than they can in the second in.

It's an abomination.