Code indenting of // postfix functions

Question

Preamble

Following the recommendation of a presentation or article which I now only vaguely remember I have been experimenting with a particular code format:

fn[args_] := (
  expr 
    // operation1
    // operation2
    // operation3
)

Each operation is cast as a Function as necessary, though operator forms are used where available. Some examples: (138146), (138650), (139228).

I have found this format to be reasonably general and have above average readability. I note that my use of it (which is by no means unique) seems to be well accepted so I think others must find it readable too.

A couple of things keep me from adopting this format as my go-to style: the first is the requirement for additional Function constructs over more heavily bracketed code. The second is the way that this code is automatically formatted in Notebook Input Cells which is what my question is about.

(Pardon the long introduction but I feel that context is necessary.)

Summary

When multiple // postfix operations are written one on each line the standard code indenter does this:

I find this indenting weird and inconvenient. I suppose it exists to indicate that operation1 is "inside" operation5, etc., but that's not really how I think about these operations; rather I think of them as a series of sequential steps performed in order from one to five.

It also ends up crowding code into the right margin when there would otherwise be plenty of room.

Question

All that out of the way my actual question is this: do other people regularly benefit from the indenting shown above, and what coding style(s) is it useful for?

If this indenting is not of use in other styles or from different perspectives I would perhaps campaign to have the indenting changed in future versions to the vertically aligned form shown in the first code block in this question.

Answer 1

As requested, I'll expand on my comment a little. The indentation makes sense if you look at the following comparison of four constructs, where the first one is from the original question:

You see the same indentation in the first two examples, and the opposite indentation in the remaining two. The examples built with just Lists illustrate that the indentation is determined by the nesting level. The more deeply nested, the larger the automatic number of LineIndents is. Recall that the actual interpretation of the input for fn is operation3[operation2[operation1[expr]]].

This is why the indentation decreases downward in the first two examples but increases in the last two: as the List constructs make explicit, the operations nearest to expr are deepest. The @ operator is the "counterpart" of // in that it allows you to reverse the order of operators and arguments. This reversal is what causes the reversed indentation.

In conclusion, the choice of indentation is consistent with the general prescription followed by the notebook interface, to indent according to nesting level. Changing this for // alone would then give you inconsistent indentation if you also use @ (or in fact any other nested expressions).