About the Expressiveness of D

[Jonathan M Davis]

On Tuesday, April 02, 2013 22:44:15 Andrei Alexandrescu wrote:
> On 4/2/13 10:13 PM, Jonathan M Davis wrote:
> > On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
> >> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> >>> I usually find the build in unittests to cause more skew since those are
> >>> counted as LOC.
> >> 
> >> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the
> >> fix.
> >> 
> >> I'm inordinately pleased with how well unittests have become embedded in
> >> our D culture.
> > 
> > Yes, though I've had complaints before about a pull being too much code
> > where the unit tests were considered part of the code, and the reviewer
> > thought that number of lines was too great to be worth adding, even if
> > the number of lines of normal code was relatively small. And that sort of
> > attitude would just lead to not properly unit testing stuff.
> 
> I think it leads to writing less repetitive unittests.
> 
> If we did datetime all over again, I'd give a budget of 2000 lines for
> all functionality. I bet the solution would be better.

I very much doubt that you could do that unless you specifically formatted the 
code to take up as few lines as possible and didn't count the unit tests or 
documentation in that line count. Otherwise, you couldn't do anything even 
close to what std.datetime does in that few lines. Sure, some functionality 
could be stripped, but you'd end up with something that did a lot less if it 
were that small. The unit tests and documentation do make it seem like a lot 
more code than it is, since they take up well over half the file (probably 
3/4), but you'd definitely lose functionality with that few lines of code, and 
you'd end up with something very poor IMHO if those 2000 lines included the 
documentation and unit tests. You'd either end up with something that was very 
bare-bones and/or something which was poorly tested, and given how easy it is 
to screw up some of those date/time calculations, having only a few tests 
would be a very bad idea.

std.datetime's unit tests do need some refactoring (some of which I've done, 
but there's still a fair bit of work to do there), which will definitely reduce 
the number of LOC that they take up, but I don't agree at all with considering 
the unit tests as part of the LOC of file when discussing keeping LOC to a 
minimum. And while it's good to avoid repetitive unit tests, I'd much rather 
have repetitive unit tests which are thorough than short ones which aren't. I 
find your focus on trying to keep unit tests to a minimum to be disturbing and 
likely to lead to poorly tested code.

If anything, we need to be more thorough, not less. That doesn't mean that the 
tests need to look like what std.datetime has (particularly since I 
purposefully avoided loops and other more complicated constructs when I wrote 
them originally in order to make them as simple and as far from error-prone as 
possible), but unit tests need to be thorough, and while we're getting better, 
Phobos' unit tests frequently aren't thorough enough (particularly in 
std.range and std.algorithm when it comes to testing a variety of range 
types). Too many of them just test a few cases to make sure that the most 
obvious stuff works rather than making sure they test corner cases and whatnot.

- Jonathan M Davis