Why are vertical and horizontal spacing heavily used in coding styles?

Question

Why would so many repositories use additional — apparently unnecessary — vertical and horizontal space in coding styles?

I almost unanimously see this:

    public function getName() {
            return 'webauthn';
    }


    public function newKey( array $data = [] ) {
            if ( empty( $data ) ) {
                    return WebAuthnKey::newKey();
            }
            return WebAuthnKey::newFromData( $data );
    }

Whereas I personally would write this:

public function getName() {return 'webauthn';}

public function newKey( array $data = [] ) {
  if ( empty( $data ) ) {return WebAuthnKey::newKey();}
  return WebAuthnKey::newFromData( $data );
}

The more compact coding style allows to see on one screen page much more details of a component and I can much faster see what the component is supposed to do.

However, the compact style seems rarely used, whereas the (over?)use of horizontal and vertical spacing are extremely popular. So I wonder: are there some reasons that would explain the need for extra spacing which I fail to understand?

Disclaimer: I am asking this here as a comment on https://stackoverflow.com/questions/74159241/why-vertical-and-horizontal-white-space-verbosity-in-coding-styles pointed out this could be the right place.

Answer 1

The real question is: why did you stop removing spaces where you did? Why not suppress the remaining line ? Why not put every statement of a function in a single line and let the editor arrange the layout to show you the long line by splitting it on several?

Another question is why the musicians put so much silence in a piece of music, when they could just make each note folllow the next without waiting?

It appears that horizontal and vertical space contribute — as much as silence in music — to add structure and to express the intent. The visual structure helps to browse quicker through large chuncks of code. Now, 2 spaces per indent or 8 spaces is a matter of taste.

The fact of always using the same layout, for example starting the if-bloc on the line following the if, has also an advantage of consistency, adopting the same style systematically. Gaining space at all cost, sometimes compressing the if and the block on one line, is not, in line with the principle of least surprise, and make the code more difficult to read for everybody else but the author.

Answer 2

Tldr

Layout is part of the syntax of programming languages, even if it isn't defined as such and the compiler ignores it.

Long read

One thing to note is that the actual syntax of many programming languages as defined in the book, does not match the perceived syntax as coders know it.

That is, in many programming languages the whitespace is not significant to the compiler. But whitespace is considered significant by coders.

If you start from that idea, then the real question is not why the code isn't more compact, but why it contains all those extra braces and semicolons (which reiterate indentations and newlines).

What you often get in C-derived languages, is a belt-and-braces approach, where the whitespace exists predominantly for the human reader, and the punctuation actually exists as a supplement purely for the compiler.

Another thing to note is that humans don't by default read like computers do. Computers parse strings serially and have no intrinsic two-dimensional representation. Humans appreciate matters like layout before they have even started reading the characters.

To emphasise the point, the human reader probably gets the gist of what's going on here, even without the semicolons and braces and brackets:

public function getName()
    return 'webauthn'

public function newKey( array $data = [] )
    if empty( $data )
        return WebAuthnKey::newKey()   
    
    return WebAuthnKey::newFromData( $data )

In fact all that additional punctuation only seems to become necessary when layout principles seems to be violated.

In terms of why this particular style of layout is most commonly used, I suggest because it is the most convenient and flexible way to represent trees or hierarchy.

Why are hierarchies important? Because basically every mainstream language follows the block-structure principle (the justification of which would be another question!).

In your "compact" version of the code, clearly a lot of layout principles have been discarded, and what exists is an anomalous layout that relies much more heavily on what I consider to be the "compiler crutches" - the things that are in the language mostly for the benefit of the compiler, not for any sensible human reader.

The example of compactification you give is simple enough, but quite obviously with more nested blocks and more statements per block, either you would have to revert to the normal style of layout (which you consider extravagant), or else the code would become very messy indeed. Messy for the human I mean - the compiler can read things that no human coder would consider reasonable.

Also, making more complicated additions to your code would require not only relevant statements to be added, but also for the overall layout to be uncompactified.

For most, the benefit of occasionally saving a line or two, is just not worth consideration.

Answer 3

In the first example, the visual layout reflects the logical structure better, because the lexical blocks are visually offset. This makes it easier to understand the logical structure at a glance.

Furtermore, the first example is more consistent since all lexical blocks are indented. In the second example, some blocks are indented (e.g. the body of the second function) while others are not.

You personally prioritize compactness (allowing you to see more code on the screen at a time) above readability. If that works for you, this is fine, but most teams prioritize readability and consistency above compactness, which is not usually a big concern. So this is why you see the "spacious" style more often.

Although whether to use 2 or 4 or 8 spaces for indents is basically arbitrary. Here consistency is the priority: Use what is standard for the code base or for the language. Same with placement of the opening brace - use what is standard for the code base and language.

Answer 4

With any data structure sparse vs dense is fundamental to the time space trade off.⁼ It's just as true when the data structure is source code. Empty space costs us space but saves us time. We consider code that takes little time to read more readable.

When you optimize source code for space you neglect time. As proof I offer all of Code Golf. ⁼

A particular example:⁼

from math import*
C=sorted(input());l,h=1e-99,1/max(C)
while h-l>2e-16:m=(l+h)/2;a=[asin(c*m)for c in C[:-1]];f=pi-sum(a);l,h=[l,m,h][sin(f)/m>C[-1]:][:2]
print sum(sin(2*t)/l/l for t in a+[f])/8

vs

def segment_angles(line_segments, invd):
    return [2*math.asin(c*invd) for c in line_segments]

def cyclic_ngon_area(line_segments):
    line_segments = list(sorted(line_segments))
    lo, hi = 1e-99, 1/max(line_segments)
    while hi - lo > 2e-16:
        mid = (lo + hi) / 2
        angles = segment_angles(line_segments[:-1], mid)
        angles.append(2*math.pi - sum(angles))
        if math.sin(angles[-1]/2) / mid > line_segments[-1]:
            lo = mid
        else:
            hi = mid
    return sum([math.sin(a)/lo/lo/8 for a in angles])

These both do the same thing. But which one takes you longer to read? That's worth a little extra space.

As for your particular example, my preferred form is:

public function getName() {
    return 'webauthn';
}

public function newKey( array $data = [] ) {
    if ( empty( $data ) ) {
        return WebAuthnKey::newKey();
    }
    return WebAuthnKey::newFromData( $data );
}

The reason I prefer this is because I like being able to add lines without touching the structure.

public function newKey( array $data = [] ) {
    if ( empty( $data ) ) {
        log.info("Creating new key without data");
        return WebAuthnKey::newKey();
    }
    return WebAuthnKey::newFromData( $data );
}

Adding that line with your form would have involved moving curly braces around. That is hard on my fingers, my brain, and source control diff tools.

However, you are not the only detractor this form has. One of the most famous is Uncle Bob. Robert Martin has said, "One of my favorite things to do is getting rid of useless braces". He would say you still have too much because you left the useless braces around one line. I questioned his approach in one of my previous posts.⁼

At the end of the day the most important thing is being appropriate to how it's used. Source code is used by your team. So the opinion that really matters is theirs. Write stuff they can read.

P.S. As for 2 vs 4 spaces for indenting, I actually appreciate 2. But I'm one of those weird ones that rotates their monitor.

Answer 5

• horizontal space is/was limited (80 symbols for text terminals without scrolling as example)

• it is inconvenient for eyes to scan long lines or constantly scroll right and back each line wider then window/screen

• one statement for one line - useful for fast understanding

https://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-code