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.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

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

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.
>
> - Jonathan M Davis

Sure, I get why you would want to structure it like that. Just saying that it's probably the reason for Phobos "fluffyness"/330 kloc then?

On Friday, 18 September 2020 at 03:01:26 UTC, Andrej Mitrovic wrote:
> On Thursday, 17 September 2020 at 15:51:18 UTC, Andrei Alexandrescu wrote:
>> As wc -l counts, phobos has some 330 KLOC:
>
> I'm sorry but the real problem is the mammoth modules. There are multiple modules reaching over 10K lines. Fixing the whitespace won't improve things much.

I totally agree. It should be possible to have N files in one module. Yes, this can be achieved with package.d to some extend. But it is rather a makeup for the "import" line (imo).

Regarding the code formating. How about a dfmt included in the standard instalation package? It could be implemented as a lib in Phobos. And if this dfmt could load its rules from a EditorConfig-like file, this file could define dfmts default behavior. But projects could ship their own ruleset but still use a standard tool for it that would come with every installation.

On Sat, 2020-09-19 at 09:55 +0000, Imperatorn via Digitalmars-d wrote:
> 
[…]
> 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 suspect getting data before coming to a view is probably the wise thing to do. Andrei's "fluffiness" may be an issue of unit tests, but given the posts in the thread I get the feeling it is more than just that.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Saturday, 19 September 2020 at 11:29:37 UTC, Russel Winder wrote:
> On Sat, 2020-09-19 at 09:55 +0000, Imperatorn via Digitalmars-d wrote:
>> 
> […]
>> 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 suspect getting data before coming to a view is probably the wise thing to do. Andrei's "fluffiness" may be an issue of unit tests, but given the posts in the thread I get the feeling it is more than just that.

What I meant is maybe it's not top priority

On Saturday, 19 September 2020 at 10:47:01 UTC, Martin wrote:
> How about a dfmt [...] if this dfmt could load its rules from a EditorConfig-like file [...]

OMG! No way! I just realized that there is a a package called dfmt and it does exactly this LOL - SRY for OT but.. If you could see my face right now...

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.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

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.

:-)

On 9/19/20 5:15 AM, Imperatorn wrote:
> On Saturday, 19 September 2020 at 06:59:54 UTC, Jonathan M Davis wrote:
>> On Friday, September 18, 2020 6:05:39 AM MDT Imperatorn via Digitalmars-d wrote:
>>> On Friday, 18 September 2020 at 07:41:25 UTC, mw wrote:
>>> > On Friday, 18 September 2020 at 06:50:48 UTC, Imperatorn
> 
>> No. It's very common practice in D code to put the tests immediately after the code that they're testing. It makes it far easier to make sure that everything has tests as well making it easier to maintain the code and ensure that the code and tests are properly in sync. In addition to that, if a unittest block immediately after a symbol is marked with a ddoc comment, then it gets added to the documentation for that symbol, making it easy to add examples to the documentation and have those examples be tested whenever you run the unit tests without having to duplicate the examples and worry about whether they're in sync between the documentation and the tests.
>> ...
>>
>> - 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.

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.