On Saturday, 19 September 2020 at 17:52:27 UTC, Patrick Schluter wrote:
> On Saturday, 19 September 2020 at 16:12:52 UTC, data pulverizer wrote:
>> On Saturday, 19 September 2020 at 15:08:12 UTC, Andrei Alexandrescu wrote:
>>> [...]
>>
>> I guess you could set a line width guide to make the code more readable. My issue with 4 space indents is in the best case scenario, you end up with a large rectangular block of white space running straight down the left hand side of the function/struct/class/whatever, and you can get these side-ways mountains of white space where you have to scroll to the right to actually see the code.
>>
>> [...]
>
> Yeah, 2 wide and no tabs. The only right rule. ;-)

I think the only right rule is to use a code formatting tool and provide the configuration so everyone can use their preferred style and format the code before committing it.

On Sunday, 20 September 2020 at 01:00:43 UTC, wjoe wrote:
> ...
> I think the only right rule is to use a code formatting tool and provide the configuration so everyone can use their preferred style and format the code before committing it.

May I ask how this works when comparing differences between files from server with local?

Matheus.

On Saturday, 19 September 2020 at 12:27:27 UTC, Russel Winder wrote:
> On Sat, 2020-09-19 at 11:44 +0000, Imperatorn via Digitalmars-d wrote:
>> 
> […]
>> What I meant is maybe it's not top priority
>
> I can agree that that may well be the case. Though the unit test code may
> suffer some of the same "fluffiness" that the library code does.

True

On Thursday, 17 September 2020 at 15:51:18 UTC, Andrei Alexandrescu 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. The total number of empty lines:
>
> $ git grep '^$' $(git ls-files '*.d') | wc -l
>    38503
>
> So Phobos has 11.62% empty lines in it, on average one on every 9 lines of code. I find that a bit excessive, particularly given that our coding convention uses brace-on-its-own line, which already adds a lot of vertical space. Here's the number of lines consisting of only one brace:
>
> git grep '^ *[{}] *$' **/*.d | wc -l
>    53126
>
> That's 16% of the total. Combined with empty lines, we're looking at a 27.65% fluff factor. Isn't that quite a bit, even considering that documentation requires empty lines for paragraphs etc?

Just for fun, I decided to run these calculations on sumtype, which uses my own personal formatting style:

Lines: 2389 total
Blank: 435 (18%)
Brace: 133 (6%)
Fluff factor: 24%

I'm clearly a lot less shy about using blank lines in my code than the average Phobos contributor, but I don't put opening braces on their own lines, so I end up with about the same level of fluff overall.

I wonder if this is a coincidence, or if "readable" code in curly-brace languages naturally converges to around 25% fluff? Further research is needed.

On Sunday, 20 September 2020 at 15:04:35 UTC, Paul Backus wrote:
> Just for fun, I decided to run these calculations on sumtype, which uses my own personal formatting style:
>
> Lines: 2389 total
> Blank: 435 (18%)
> Brace: 133 (6%)
> Fluff factor: 24%

omg ima do it too:

Lines: 156097 total
Blank: 22552 (14%)
Brace: 5 (0%)
Fluff factor: 14%


Would be kinda interesting to compare byte size and number of lexemes too, to get an idea of average line length. 4780494 is what wc says to me which makes my average populated line 36 chars long.

Phobos wc gives 11320840 which makes its average populated line 47 chars long. Interesting but prolly meaningless.

On 9/20/20 11:04 AM, Paul Backus wrote:
> On Thursday, 17 September 2020 at 15:51:18 UTC, Andrei Alexandrescu 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. The total number of empty lines:
>>
>> $ git grep '^$' $(git ls-files '*.d') | wc -l
>>    38503
>>
>> So Phobos has 11.62% empty lines in it, on average one on every 9 lines of code. I find that a bit excessive, particularly given that our coding convention uses brace-on-its-own line, which already adds a lot of vertical space. Here's the number of lines consisting of only one brace:
>>
>> git grep '^ *[{}] *$' **/*.d | wc -l
>>    53126
>>
>> That's 16% of the total. Combined with empty lines, we're looking at a 27.65% fluff factor. Isn't that quite a bit, even considering that documentation requires empty lines for paragraphs etc?
> 
> Just for fun, I decided to run these calculations on sumtype, which uses my own personal formatting style:
> 
> Lines: 2389 total
> Blank: 435 (18%)
> Brace: 133 (6%)
> Fluff factor: 24%
> 
> I'm clearly a lot less shy about using blank lines in my code than the average Phobos contributor, but I don't put opening braces on their own lines, so I end up with about the same level of fluff overall.
> 
> I wonder if this is a coincidence, or if "readable" code in curly-brace languages naturally converges to around 25% fluff? Further research is needed.


I put blank lines everywhere. I need the fluff for it to look reasonable. You will also see a lot of comments in my code too. I used to do a 3-line comment using 2 blank // lines above and below, but I now think a blank line (without the //) before the comment suffices. Meh, I like readability, and I don't see the harm in it.

This is one of the largest rubble-bouncing threads I've seen in a while.

-Steve

On 9/20/20 11:15 AM, Adam D. Ruppe wrote:
> On Sunday, 20 September 2020 at 15:04:35 UTC, Paul Backus wrote:
>> Just for fun, I decided to run these calculations on sumtype, which uses my own personal formatting style:
>>
>> Lines: 2389 total
>> Blank: 435 (18%)
>> Brace: 133 (6%)
>> Fluff factor: 24%
> 
> omg ima do it too:
> 
> Lines: 156097 total
> Blank: 22552 (14%)
> Brace: 5 (0%)
> Fluff factor: 14%

Interesting, thanks.

> Would be kinda interesting to compare byte size and number of lexemes too, to get an idea of average line length. 4780494 is what wc says to me which makes my average populated line 36 chars long.
> 
> Phobos wc gives 11320840 which makes its average populated line 47 chars long. Interesting but prolly meaningless.

I think you'd need to adjust for tabs - you need to multiply tabs by 4.

On 9/20/20 11:18 AM, Steven Schveighoffer wrote:
> This is one of the largest rubble-bouncing threads I've seen in a while.

Not to worry, there's no action item here (save for "we should set up an automatic formatter sometime"). In particular, my latest refactorings aim at reducing code size "for real", not by just removing blank lines.

On Sunday, 20 September 2020 at 15:28:53 UTC, Andrei Alexandrescu wrote:
> I think you'd need to adjust for tabs - you need to multiply tabs by 4.

Oh yeah, that'd pretty well account for the difference.

I also need to fix the braces thing, that should be 2917, not 5 due to spaces and tabs. So that adds 2% to my fluff bringing it to 16%.

Anyway, I have 217080 precious, beautiful, perfect tabs in there. So that makes my total length in spaces 5431734 / 130628 corrected non-blank lines = 42 average. Still slightly shorter but pretty close.

Like I said, it is probably meaningless, but a bit amusing since I'm so staunchly anti line length limits... but it seems to converge around the same length anyway.

On Sunday, 20 September 2020 at 16:11:44 UTC, Adam D. Ruppe wrote:

> Like I said, it is probably meaningless, but a bit amusing since I'm so staunchly anti line length limits... but it seems to converge around the same length anyway.

Interesting. How long are your longest lines?

awk '{print length}' | sort -rn | head