Is phobos too fluffy?

Andrei Alexandrescu SeeWebsiteForEmail at
Thu Sep 17 17:15:49 UTC 2020

On 9/17/20 12:34 PM, H. S. Teoh wrote:
> On Thu, Sep 17, 2020 at 11:51:18AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
>> As wc -l counts, phobos has some 330 KLOC:
>> $ wc -l $(git ls-files '*.d') | tail -1
>>    331378 total
>> I noticed many contributors are fond of inserting empty lines
>> discretionarily, sometimes even in the middle of 2-5 line functions,
>> or right after opening an "if" statement.
> Do you have a concrete example of this?

Only everywhere I look. Just opened std.algorithm.iteration but really 
no need to cherry-pick:

Four-liner unittest with a gratuitous empty line: 
Also uses some vertical alignment that maintainers are going to just love.

Empty line BEFORE the closing "}", that's just sloppy:

An empty line between the cases and the default of a switch: 
The switch itself is four lines. Also: the default case uses return on 
the same line, the others don't.

An empty line inexplicably just before the return of a four-liner. A 
four-liner! Who thinks this makes anything easier to read?

An empty line in the middle of a three-line block, again before the 
return (what's the deal with that)?

Three-liner unittest with an empty one added:

The list goes on...

(I recall being in a similar debate with a colleague, and he mentioned 
he separates with a newline all non-expression statements (or something 
to that effect). So if there's an if, a loop, an import, a return, a 
definition, etc. - they have newlines in between. I'd think that gets 
into career-limiting stuff, especially because said colleague had the 
air that that's really fundamental, like the theorem of structure.)

This all is a bit of a bummer. I reckon it's a popular style because 
there seem to be a lot of code in phobos like that, but it kinda is 
excessive and limits the context one can put on the screen. Worse, I saw 
that as a side-effect there's a lot of "cheating" on the full bracing - 
many places that require no full braces dispense with them. However, it 
turns out that full-bracing is useful during maintenance (you can easily 
insert or remove code), whereas empty lines aren't.

> Sure, but why are we fussing over formatting, when there are bigger fish
> to fry?  Like code quality issues: pushing sig constraints into static
> ifs when they are more suitable, merging unnecessary overloads, fixing
> documentation issues, etc..  IMO, removing empty lines is last on that
> long list of action items.

Per the Romanian saying, "til you get to God the saints will eat you 
up". Hard to translate. Meaning you try the big thing but the little 
things are going to get you first. Yah, I'm trying to do the good things 
while constantly getting sand in the eye because of the little things.

>> E.g. there should never be two consecutive empty lines, and code
>> blocks shorter than x lines should have no newlines inside.
> You mean no empty lines?  Otherwise we'd have to pack multiple
> statements onto 1 line, which I don't think is what you want. ;-)

Not no two consecutive newlines. Two consecutive empty lines, i.e. three 
consecutive newlines, \n\n\n.

More information about the Digitalmars-d mailing list