On 9/19/20 5:55 AM, Imperatorn wrote:
> On Saturday, 19 September 2020 at 09:45:13 UTC, Russel Winder wrote:
>> On Sat, 2020-09-19 at 09:15 +0000, Imperatorn via Digitalmars-d wrote:
>>> On Saturday, 19 September 2020 at 06:59:54 UTC, Jonathan M Davis
>> […]
>>>
>>> "It's very common practice"
>>>
>>> Actually no it is not. D is the only example I've seen that routinely does this. Virtually all other languages separate code and tests.
>>
>> Rust has unit tests in the source modules, just as D does. It works very well.
>>
>> Rust also has ways of doing integration and system testing, where the tests are separate. It works very well.
> 
> I get the point in doing so. What I mean is that explains why Phobos is "fluffy" then, and it's probably not a problem

I'm bothered by the prevalence of empty lines in source code, not so much unittests or documentation.

On 9/19/20 9:00 AM, data pulverizer 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 [...]
> 
> At the risk of starting WW3, I'd like to propose using 2 space code indent over 4 spaces or tabs. Indents just don't need that much space.

Jesting aside, that would actually increase average complexity of the code because it would allow people to nest more.

On Saturday, 19 September 2020 at 15:08:12 UTC, Andrei Alexandrescu wrote:
> On 9/19/20 9:00 AM, data pulverizer wrote:
>> At the risk of starting WW3, I'd like to propose using 2 space code indent over 4 spaces or tabs. Indents just don't need that much space.
>
> Jesting aside, that would actually increase average complexity of the code because it would allow people to nest more.

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.

Some time ago I used to use tabs (yikes!) to delimit my code until I took a terrible contract job. The only good thing that came out of it was that the client insisted that the code be 2-space delimited, which I didn't even know was a thing. Lol! After that job I don't do fixed cost contracts, and I indent code with 2 spaces.

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:
>> On 9/19/20 9:00 AM, data pulverizer wrote:
>>> [...]

the linux kernel has a rule: all code has to be indented with tabs. Its for a single reason: more left leaning code is faster (heh Andrei). As Andrei already mentioned, less indented code allows people to nest more, which makes for arguable worse code.[1]

What you really want is a column limit too. The linux kernel enforces 80 columns, for phobos something like 100-120 probably makes more sense. It would make sure no one writes overly nested code, and at the same time make sure you don't have to scroll all the way to the right.

[1]: https://www.kernel.org/doc/html/v4.10/process/coding-style.html

On 9/19/20 12:20 PM, Uknown 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:
>>> On 9/19/20 9:00 AM, data pulverizer wrote:
>>>> [...]
> 
> the linux kernel has a rule: all code has to be indented with tabs. Its for a single reason: more left leaning code is faster (heh Andrei). As Andrei already mentioned, less indented code allows people to nest more, which makes for arguable worse code.[1]
> 
> What you really want is a column limit too. The linux kernel enforces 80 columns, for phobos something like 100-120 probably makes more sense. It would make sure no one writes overly nested code, and at the same time make sure you don't have to scroll all the way to the right.
> 
> [1]: https://www.kernel.org/doc/html/v4.10/process/coding-style.html

Yes indeed! I do mention that in a couple of talks. Their indent size is 8, too. You can't do a lot of shenanigans with indent size 8 and max columns 80.

Many animals are beautiful because they live hard lives.

On Saturday, 19 September 2020 at 16:32:13 UTC, Andrei Alexandrescu wrote:
>
> Yes indeed! I do mention that in a couple of talks. Their indent size is 8, too. You can't do a lot of shenanigans with indent size 8 and max columns 80.
>
> Many animals are beautiful because they live hard lives.

They recently switched to 100:
https://lkml.org/lkml/2020/5/29/1038

I fully agree with your statement of complexity based on nesting, however I totally disagree with the solution.

Modern "linters" are sufficiently capable to issue an error on 3 levels of _nesting_ instead of an arbitrarily chosen max column.

Just consider some features, such as named-parameters, if anything they are more likely to reduce complexity than to increase it, however it will result in very long lines, even if the line is a single statement without nesting, being forced to break such lines will reduce readability.

On Saturday, 19 September 2020 at 15:04:25 UTC, Andrei Alexandrescu wrote:
> On 9/19/20 5:15 AM, Imperatorn wrote:
>> On Saturday, 19 September 2020 at 06:59:54 UTC, Jonathan M Davis wrote:
>>>> > [...]
>> 
>>> [...]
>> 
>> "It's very common practice"
>> 
>> Actually no it is not. D is the only example I've seen that routinely does this. Virtually all other languages separate code and tests.
>
> I just read that Python's doctest endorses the same:
>
> * https://docs.python.org/2/library/doctest.html
>
> It seems a matter in which reasonable people may disagree. I know Atila Neves doesn't like it, and he's reasonable. His reason is actually good too, of a practical nature at scale - build times/memory issues. I do agree with that reason, and that's about the only con I can every think of.
>
> There are also a few discussion on that online:
>
> * https://stackoverflow.com/questions/9022547/should-test-code-be-separate-from-source-production-code
>
> * https://softwareengineering.stackexchange.com/questions/188316/is-there-a-reason-that-tests-arent-written-inline-with-the-code-that-they-test
>
> The arguments against seem to come from folks who either never attempted to use inline tests and are doing a gedankenexperiment, or people who did try and were deterred by language limitations.
>
> This is a short article in favor of doing it, or so it seems (not sure what the context is):
>
> * https://techbeacon.com/app-dev-testing/6-reasons-co-locate-your-app-automation-code
>
> For my money, the troika documentation-implementation-unittest is sacrosanct. It's the unit of progress. I honestly consider it unkind of someone to not provide all three together. And there's a synergy of sorts: in the projects with separate unittests, guess what - documentation is absent, too.
>
> The advent of documentation unittests has made the matter all but motherhood and apple pie. Not providing such is almost going out of one's way to be a jerk to the user.

Thanks for a good reply!

I am not really saying it's a bad idea. I actually think it might be wise to do so. I mis-read the comment earlier about it being common (in other languages).
I have just completed a marathon of going through about 50 languages, so I felt I had something to say about it, that's all.

Anyway, since I'm here, at the D-Forum is kind of a good sign, right? :) I do believe D is a great language with a good deal of hope. In the coming months I will (at our company) actually port some C# to D and if it all works out I'll be really happy about D.

On Saturday, 19 September 2020 at 09:24:05 UTC, Jonathan M Davis wrote:
> On Saturday, September 19, 2020 3:15:01 AM MDT Imperatorn via Digitalmars-d wrote:
>> On Saturday, 19 September 2020 at 06:59:54 UTC, Jonathan M Davis
>>
>> wrote:
>> > [...]
>>
>> "It's very common practice"
>>
>> Actually no it is not. D is the only example I've seen that routinely does this. Virtually all other languages separate code and tests.
>
> I specifically said that it was very common practice _in D code_. You couldn't do it with most other languages even if you wanted to, because they don't have unit test functionality built into the language.
>
I introduced it the C project at work thanks to the magic of preprocessor macros and attribute((constructor)) of GCC. Works like a charm.

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. ;-)

On Saturday, 19 September 2020 at 16:12:52 UTC, data pulverizer wrote:
> [...]
> After that job I don't do fixed cost contracts, and I indent code with 2 spaces.

You could have configured your tabs to width of 2 :)