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.

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
>
> [...]

Not to criticize, but, if it has reached 330 KLOC there might be another problem :S

How did it get that big?

On Friday, 18 September 2020 at 06:50:48 UTC, Imperatorn wrote:
> Not to criticize, but, if it has reached 330 KLOC there might be another problem :S
>
> How did it get that big?

Sometimes for non-trivial program, `unittest` can easily be longer than the program itself to cover all the test paths & cases.

On Thursday, 17 September 2020 at 17:49:39 UTC, Seb wrote:
> On Thursday, 17 September 2020 at 15:51:18 UTC, Andrei Alexandrescu wrote:
>> [...]
>
> We shouldn't have these discussions.
> We should just use a code formatting tool (see e.g. how successful black was in the Python world - https://github.com/psf/black) and be done with.
>
> So IMHO the only productive discussion here is how we can get dfmt (https://github.com/dlang-community/dfmt)  (or a new tool) in a shape, s.t. it can be applied automatically.
>
> Alternatively, for your specific request, there was [1], but I since gave up on enforcing such style issues manually. As I mentioned, a tool should handle this task for you.
>
> [1] https://github.com/dlang-community/D-Scanner/pull/447


I think I hear Kenji chuckling in the distance ...

On Friday, 18 September 2020 at 07:41:25 UTC, mw wrote:
> On Friday, 18 September 2020 at 06:50:48 UTC, Imperatorn wrote:
>> Not to criticize, but, if it has reached 330 KLOC there might be another problem :S
>>
>> How did it get that big?
>
> Sometimes for non-trivial program, `unittest` can easily be longer than the program itself to cover all the test paths & cases.

Sure, but wouldn't you separate the code and tests in different projects?

On Fri, Sep 18, 2020 at 12:05:39PM +0000, 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 wrote:
> > > Not to criticize, but, if it has reached 330 KLOC there might be another problem :S
> > > 
> > > How did it get that big?
> > 
> > Sometimes for non-trivial program, `unittest` can easily be longer than the program itself to cover all the test paths & cases.
> 
> Sure, but wouldn't you separate the code and tests in different projects?

Why would you?  Keeping tests and code side-by-side makes it more likely that the two are in sync, and therefore that the tests are relevant to the current version of the code. The larger the separation, the more likely the two are out-of-sync, which in practice usually means the tests become largely irrelevant and fail to test significant functionality, and code quality drops.  Keeping tests in a separate module or a separate project altogether exacerbates this likelihood. Keeping them right next to the function being tested increases the chances of being relevant.

Besides, you really should be writing tests alongside the code as you're coding anyway.  IME, doing that has a high chance of catching bugs early and increasing code quality as a result. Postponing the writing of tests, or having to switch to a different file/project to write the test, makes it less likely tests will be written in the first place, and more likely that the tests will be general and fail to cover corner cases.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye

On 2020-09-17 18:34, H. S. Teoh wrote:

> as opposed to:
> 
> 	// Better
> 	struct MyRange(E)
> 	{
> 	    @property bool empty() { return _isEmpty; }
> 	    @property E front() { return _front; }
> 	    void popFront() { r.popFront; }
> 	}

I hate that style. But I wouldn't mind if D supported expression body definition like C# does:

struct MyRange(E)
{
    @property bool empty() => _isEmpty;
    @property E front() => _front;
    void popFront() => r.popFront;
}

It would look even better in Scala:

class MyRange[E]
{
  def empty = _isEmpty
  def front = _front
  def popFront() = r.popFront
}

In most languages in the C family, removing the curly braces for the body of `if`, `for`, `while` and so on is supported if the body only contains a single statement. Compared to Java, D extended this and allows to drop the curly braces for `try`, `catch` and `finally` as well. It just makes sense to allow to drop them for function bodies as well.

Scala goes even further and allows to drop the curly braces for classes:

class Foo

Not a very useful class but something like this also works in Scala:

class Point(x: Int, y: Int)

The above will automatically generate a instance variables, getters/setters and a constructor for the specified `x` and `y`.

Allowing to drop the curly braces is extra useful because in Scala the last statement in a method is returned automatically, that in combination with that all statements are actually expressions:

class Foo
{
  def bar(x: Int) =
    if (a == 3)
      "3"
    else if (a == 4)
      "4"
    else
      "other"
}

-- 
/Jacob Carlborg

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 wrote:
> >> Not to criticize, but, if it has reached 330 KLOC there might be another problem :S
> >>
> >> How did it get that big?
> >
> > Sometimes for non-trivial program, `unittest` can easily be longer than the program itself to cover all the test paths & cases.
>
> Sure, but wouldn't you separate the code and tests in different projects?

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.

Of course, not everyone likes to have the tests with the code, and some people will put them separately, but it's generally recommended that they go together, and that's what Phobos does. And since we try to have Phobos be both well-documented and well-tested, the vast majority of its LOC are made up of documentation and unit tests.

- Jonathan M Davis

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.

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:
> > 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 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