Agree 100%.  Leave the module as-is and let's improve the doc generator.  I don't think we should design the functionality of code around documentation issues.

-Steve



From: Michel Fortin <michel.fortin at michelf.com>
To: Discuss the phobos library for D <phobos at puremagic.com>
Cc:
Sent: Thursday, February 10, 2011 8:03 AM
Subject: Re: [phobos] Split std.datetime in two?

Le 2011-02-10 ? 0:54, Jonathan M Davis a ?crit :

> I do have one concern however. As there's a fair bit of functionality in there, there's a lot of documentation, and I'm afraid that the documentation may be a bit overwhelming to someone trying to figure out how to use std.datetime. On the whole, everything in there is quite easy to use, but there's a lot of it.

I agree that the documentation isn't very well structured; std.datetime is hardly the only module with this problem.

I disagree about restructuring the code if the goal is only to make the documentation better. The right solution is to improve the documentation generation, not to contort the code to fit a particular documentation structure. Let's ask ourself how we want the documentation to be, then lets look at how we can achieve that.

Creating a table of content sorted by task (like Andrei did for std.algorithm) looks like a good start. Another idea to address the nesting problem could be to collapse the nested declarations with a show/hide javascript button to avoid having nested declarations you don't know they belong to what (if you've explicitly disclosed some content, you should know what it is). Perhaps it'd also be nice if things could be split on multiple pages, but I'm not sure on what criterion.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



_______________________________________________
phobos mailing list
phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110210/412510fb/attachment-0001.html>

On 2/10/11 7:59 AM, Steve Schveighoffer wrote:
> Agree 100%. Leave the module as-is and let's improve the doc generator. I don't think we should design the functionality of code around documentation issues.

Same here. There are two additional options we have:

- Reduce the size of the documentation. Jonathan is not the tersest guy I know, and there is a fair amount of repetitiveness in the documentation. For example DateTime opBinary comes with a full table with four rows and five columns that conveys the simple fact that adding or subtracting a duration to a DateTime yields a DateTime. That and many other tables have identical rows (I think it's a cut and paste error; the idea might have been to swap the order of arguments, yet _still_ a table is not justified there).

- Write a separate document about dates and times in the form of a manual, and reduce the size of the documentation proper. Insert references to the manual.

Now that the topic came about I have serious concerns about code and functionality density of Phobos going forward, and that I promised myself to be extra hawkish about it.

std.datetime has 34219 lines, which accounts for over 26% of the entire Phobos size. If Jonathan will (as he promised, I didn't forget :o)) fix line sizes to conform to 80 columns, then std.datetime will become 40961 lines, or straight 30% of Phobos.

(This might have to do with the increase of "hello, world" that was noted by some people on the compiler list.)

I understand there are factors that contribute to that: date and time manipulation is a bulky endeavor, there's a ton of unittests, and there's a lot of documentation. But at a level I find it difficult to digest the fact that in sheer numbers date and time manipulation accounts for 30% of Phobos. As a comparison point, std.algorithm does arguably a lot of work, has adequate documentation, and has unittest coverage at 95%, yet does all that in a "measly" 8027 lines.

Now say we added std.unittests exactly as proposed. It has 2247 lines, which puts it at 73 percentile in terms of LOC in Phobos - just below std.stdio and above workhorses such as std.random, std.variant, and std.concurrency itself. Again, I find it difficult to convince myself that a few unittest support functions and their paraphernalia need that much real estate.


Andrei

On Thursday, February 10, 2011 07:15:44 Andrei Alexandrescu wrote:
> On 2/10/11 7:59 AM, Steve Schveighoffer wrote:
> > Agree 100%. Leave the module as-is and let's improve the doc generator. I don't think we should design the functionality of code around documentation issues.
> 
> Same here. There are two additional options we have:
> 
> - Reduce the size of the documentation. Jonathan is not the tersest guy I know, and there is a fair amount of repetitiveness in the documentation. For example DateTime opBinary comes with a full table with four rows and five columns that conveys the simple fact that adding or subtracting a duration to a DateTime yields a DateTime. That and many other tables have identical rows (I think it's a cut and paste error; the idea might have been to swap the order of arguments, yet _still_ a table is not justified there).
> 
> - Write a separate document about dates and times in the form of a manual, and reduce the size of the documentation proper. Insert references to the manual.
> 
> Now that the topic came about I have serious concerns about code and functionality density of Phobos going forward, and that I promised myself to be extra hawkish about it.
> 
> std.datetime has 34219 lines, which accounts for over 26% of the entire Phobos size. If Jonathan will (as he promised, I didn't forget :o)) fix line sizes to conform to 80 columns, then std.datetime will become 40961 lines, or straight 30% of Phobos.
> 
> (This might have to do with the increase of "hello, world" that was noted by some people on the compiler list.)
> 
> I understand there are factors that contribute to that: date and time manipulation is a bulky endeavor, there's a ton of unittests, and there's a lot of documentation. But at a level I find it difficult to digest the fact that in sheer numbers date and time manipulation accounts for 30% of Phobos. As a comparison point, std.algorithm does arguably a lot of work, has adequate documentation, and has unittest coverage at 95%, yet does all that in a "measly" 8027 lines.
> 
> Now say we added std.unittests exactly as proposed. It has 2247 lines, which puts it at 73 percentile in terms of LOC in Phobos - just below std.stdio and above workhorses such as std.random, std.variant, and std.concurrency itself. Again, I find it difficult to convince myself that a few unittest support functions and their paraphernalia need that much real estate.

Well, as Steven says, most of std.datetime is unit tests. And probably over half of the rest is documentation, since most of the functions themselves are relatively short and simple. Add to that that I tend to like a fair bit of vertical space in my  code (e.g. return statements pretty much always have a blank line above them), and how I code tends to take up a fair bit more LOC than you would without actually being more code. It wouldn't surprise me that if I were to format std.algorithm in a manner that I'd typicall write it, it would at least double in line count simply due to additional blank lines that I'd introduce for code legibility. And, of course, if I'd written std.algorithm, it would almost certainly have had quite a few more unit tests. None of that increases the size of the actual binary. I don't think that std.datetime is the largest module in Phobos, but I do think that comparing its line count to something like std.algorithm really tells you how much of a difference it makes in the size of the binary - especially when so much of it is unit tests which wouldn't end up in a binary.

The unit testing functions I wrote are pretty much in the same boat. They had thorough unit tests - testing not only all of its code paths (which is what the % code coverage gives you) but an appropriate range of values. The functions themselves weren't all that long.

If we really want to know why hello world is so large, I think that we need to do as Walter suggests and actually investiage that with -map. std.datetime almost certainly does contribute to that, but so much of it is unit tests that I have a hard time believing that it did all that much to increase the size of the binary. And the reality of the matter is that as the functionality of Phobos increases, the amount of code that it has will increase. And as long as all D binaries are statically linked, that means that the size of the binary is going to increase. That's just a fact of life. And if the standard libraries of Java and C# are any indication of the typical size of a standard library, then Phobos could get quite large eventually. Obviously, that takes time and effort, so Phobos is not going to be enormous like that any time soon, but it's size _is_ going to continue to increase if we want a full-featured standard library.

- Jonathna M Davis


P.S. Weren't you considering increasing the character limit beyond 80? I'm not about to go and edit std.datetime for line width until that's definitely decided. At the moment, I'm working on improving the documentation (mostly for consistency rather than length, though its length should be somewhat reduced when I'm done) and that will make the documentation and examples at most 80 characters wide, but I haven't started in on the rest of it yet. Most of the long lines are unit tests though, I believe (some of which are ludicrously long simply because it's easier to read an assertion on a single line).

On 02/10/2011 04:15 PM, Andrei Alexandrescu wrote:
> - Write a separate document about dates and times in the form of a manual, and reduce the size of the documentation proper. Insert references to the manual.

Very good solution, I guess. (but it must be done, and well done)

FWIW: once collegues and myself had to face similar doc issues (about pedagogic material). We ended up stating the following rule: when the /domain/ a tool addresses is problematic in itself, then write a separate guide for it. Else write the doc for the tool itself, with the presupposition the domain is not an issue, and people only need some hints about the tool itself. If it is properly designed, the inline doc should be both short & simple; else, it may reveal design issues.

I guess (just my opinion) DateTime's domain clearly calls for a separate doc: issues on date/time counting, time zones, locale formats, etc, are all but trivial and well-known. (And I don't even evoke other calendar systems ;-) What do you think?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 10 feb 2011, at 18:33, Jonathan M Davis wrote:
> - Jonathna M Davis
> 
> 
> P.S. Weren't you considering increasing the character limit beyond 80? I'm not
> about to go and edit std.datetime for line width until that's definitely decided.
> At the moment, I'm working on improving the documentation (mostly for
> consistency rather than length, though its length should be somewhat reduced
> when I'm done) and that will make the documentation and examples at most 80
> characters wide, but I haven't started in on the rest of it yet. Most of the
> long lines are unit tests though, I believe (some of which are ludicrously long
> simply because it's easier to read an assertion on a single line).
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

There are tools that does this for you. Descent, for example, has support for automatically formatting the code with just a click on a button.

-- 
/Jacob Carlborg

On Thursday, February 10, 2011 11:17:45 Jacob Carlborg wrote:
> On 10 feb 2011, at 18:33, Jonathan M Davis wrote:
> > - Jonathna M Davis
> > 
> > 
> > P.S. Weren't you considering increasing the character limit beyond 80?
> > I'm not about to go and edit std.datetime for line width until that's
> > definitely decided. At the moment, I'm working on improving the
> > documentation (mostly for consistency rather than length, though its
> > length should be somewhat reduced when I'm done) and that will make the
> > documentation and examples at most 80 characters wide, but I haven't
> > started in on the rest of it yet. Most of the long lines are unit tests
> > though, I believe (some of which are ludicrously long simply because
> > it's easier to read an assertion on a single line).
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> 
> There are tools that does this for you. Descent, for example, has support for automatically formatting the code with just a click on a button.

Yeah. And the result is almost always horrible. I'd much rather just do it myself.

- Jonathan M Davis

On 2/10/11 11:33 AM, Jonathan M Davis wrote:
> Well, as Steven says, most of std.datetime is unit tests. And probably over half of the rest is documentation, since most of the functions themselves are relatively short and simple.

That means there are too many unit tests. There is such a thing as too much of a good thing.

> Add to that that I tend to like a fair bit of
> vertical space in my  code (e.g. return statements pretty much always have a
> blank line above them), and how I code tends to take up a fair bit more LOC than
> you would without actually being more code.

As I mentioned, it would be courteous to your other colleagues if you were more economical with vertical space. Many people (and most of Phobos devs) consider vertical space a rare commodity.

> It wouldn't surprise me that if I
> were to format std.algorithm in a manner that I'd typicall write it, it would at
> least double in line count simply due to additional blank lines that I'd
> introduce for code legibility.

I consider legible code compact code that I can keep on one screen and understand what it does.

> And, of course, if I'd written std.algorithm, it
> would almost certainly have had quite a few more unit tests. None of that
> increases the size of the actual binary.

It's not the size of the binary I'm worried about.

> I don't think that std.datetime is the
> largest module in Phobos, but I do think that comparing its line count to
> something like std.algorithm really tells you how much of a difference it makes
> in the size of the binary - especially when so much of it is unit tests which
> wouldn't end up in a binary.

One thing is certain: someone who wants to take a look at std.datetime has the prospect of navigating 34KLOC.

> The unit testing functions I wrote are pretty much in the same boat. They had thorough unit tests - testing not only all of its code paths (which is what the % code coverage gives you) but an appropriate range of values. The functions themselves weren't all that long.

They are unrolled loops that should be rolled. Most likely they test the same thing several times.

> P.S. Weren't you considering increasing the character limit beyond 80? I'm not about to go and edit std.datetime for line width until that's definitely decided. At the moment, I'm working on improving the documentation (mostly for consistency rather than length, though its length should be somewhat reduced when I'm done) and that will make the documentation and examples at most 80 characters wide, but I haven't started in on the rest of it yet. Most of the long lines are unit tests though, I believe (some of which are ludicrously long simply because it's easier to read an assertion on a single line).

Generally I don't want to impose something as much as us all reaching a consensus about it. Some of Phobos people (I recall you and Don) prefer larger limits. On the other hand, there _are_ some things that will never reach an agreement so someone needs to just set some limits.


Andrei

On Thursday, February 10, 2011 14:28:22 Andrei Alexandrescu wrote:
> On 2/10/11 11:33 AM, Jonathan M Davis wrote:
> > Well, as Steven says, most of std.datetime is unit tests. And probably over half of the rest is documentation, since most of the functions themselves are relatively short and simple.
> 
> That means there are too many unit tests. There is such a thing as too much of a good thing.
> 
> > Add to that that I tend to like a fair bit of
> > vertical space in my  code (e.g. return statements pretty much always
> > have a blank line above them), and how I code tends to take up a fair
> > bit more LOC than you would without actually being more code.
> 
> As I mentioned, it would be courteous to your other colleagues if you were more economical with vertical space. Many people (and most of Phobos devs) consider vertical space a rare commodity.
> 
> > It wouldn't surprise me that if I
> > were to format std.algorithm in a manner that I'd typicall write it, it
> > would at least double in line count simply due to additional blank lines
> > that I'd introduce for code legibility.
> 
> I consider legible code compact code that I can keep on one screen and understand what it does.

There aren't very many functions in std.datetime which wouldn't fit one one screen. Regardless, it's obvious that code legibility is a subjective thing.

> > And, of course, if I'd written std.algorithm, it
> > would almost certainly have had quite a few more unit tests. None of that
> > increases the size of the actual binary.
> 
> It's not the size of the binary I'm worried about.
> 
> > I don't think that std.datetime is the
> > largest module in Phobos, but I do think that comparing its line count to
> > something like std.algorithm really tells you how much of a difference it
> > makes in the size of the binary - especially when so much of it is unit
> > tests which wouldn't end up in a binary.
> 
> One thing is certain: someone who wants to take a look at std.datetime has the prospect of navigating 34KLOC.
> 
> > The unit testing functions I wrote are pretty much in the same boat. They had thorough unit tests - testing not only all of its code paths (which is what the % code coverage gives you) but an appropriate range of values. The functions themselves weren't all that long.
> 
> They are unrolled loops that should be rolled. Most likely they test the same thing several times.

Some of them could be easily turned into loops - others not (most probably not). They don't generally quite test a set of consecutive values, though there is often a pattern to them. I tend to dislike doing much complicated just to try and reduce the lines in a unit test, because the risk of screwing it up goes up, and if the tests are wrong, the code will be wrong. So, the tests are simple but repetitive.

The risk of screwing up like that for std.datetime is lower at this point, since it has already been thoroughly tested (the likelihood of a test failure when changing the tests is now much more likely to be a screwed up test rather than the code being broken). So, I'd be far more willing to try to alter the tests to take up less space now that I would have been when writing it.

I suppose that I could look at trying to turn some of the tests into arrays which get looped over. That sort of thing is not always going to be possible though, regardless of how repetitive the tests may seem. And while the functions aren't generally long, and _most_ of them are simple, there _are_ some of them with calculations which are easy to screw up, and a lot of tests are necessary to catch edge cases and the like. For instance, at one point, I thought that I'd finally gotten the gregorian day calculations right only to find that when I added tests for negative years which ended in 99, the result was always 1 day off. I only caught it because I had a lot of tests.

While I'm fine with the tests as they are, obviously others aren't. So, I'll see if I can reasonably reduce how many lines they take up. But I'm not particularly willing to reduce what's being tested.

> > P.S. Weren't you considering increasing the character limit beyond 80? I'm not about to go and edit std.datetime for line width until that's definitely decided. At the moment, I'm working on improving the documentation (mostly for consistency rather than length, though its length should be somewhat reduced when I'm done) and that will make the documentation and examples at most 80 characters wide, but I haven't started in on the rest of it yet. Most of the long lines are unit tests though, I believe (some of which are ludicrously long simply because it's easier to read an assertion on a single line).
> 
> Generally I don't want to impose something as much as us all reaching a consensus about it. Some of Phobos people (I recall you and Don) prefer larger limits. On the other hand, there _are_ some things that will never reach an agreement so someone needs to just set some limits.

We need a decision or consesus of some kind. I really hate the 80 character limit, but we need to decide on a limit of some kind - be it 80, 100, 120 or whatever. Once we've decided, I can make std.datetime match it.

It was discussed on the D list, but no decision was actually ever made from what I can tell.  Sean, Don, and I all wanted longer line counts (100+). Other folks wanted 80. However, most of the folks who chimed in on that thread aren't Phobos developers, for however much that matters (in fact, other than you, I think that Steven might have been the only other Phobos developer to chime in - unless you count Walter's vote of 1 mol). Going off of just the Phobos developers in that thread, the consensus would be something around 100, but that was definitely not all of them.

I'd love it if the limit were something more like 100 than 80, but at this point, I think that a decision just needs to be made.

- Jonathan M Davis

On Feb 11, 2011, at 12:24 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Thursday, February 10, 2011 14:28:22 Andrei Alexandrescu wrote:
>> On 2/10/11 11:33 AM, Jonathan M Davis wrote:
>>> Well, as Steven says, most of std.datetime is unit tests. And
>>> probably
>>> over half of the rest is documentation, since most of the functions
>>> themselves are relatively short and simple.
>>
>> That means there are too many unit tests. There is such a thing as
>> too
>> much of a good thing.
>>
>>> Add to that that I tend to like a fair bit of
>>> vertical space in my  code (e.g. return statements pretty much
>>> always
>>> have a blank line above them), and how I code tends to take up a
>>> fair
>>> bit more LOC than you would without actually being more code.
>>
>> As I mentioned, it would be courteous to your other colleagues if you were more economical with vertical space. Many people (and most of Phobos devs) consider vertical space a rare commodity.
>>
>>> It wouldn't surprise me that if I
>>> were to format std.algorithm in a manner that I'd typicall write
>>> it, it
>>> would at least double in line count simply due to additional blank
>>> lines
>>> that I'd introduce for code legibility.
>>
>> I consider legible code compact code that I can keep on one screen
>> and
>> understand what it does.
>
> There aren't very many functions in std.datetime which wouldn't fit
> one one
> screen. Regardless, it's obvious that code legibility is a
> subjective thing.
>
>>> And, of course, if I'd written std.algorithm, it
>>> would almost certainly have had quite a few more unit tests. None
>>> of that
>>> increases the size of the actual binary.
>>
>> It's not the size of the binary I'm worried about.
>>
>>> I don't think that std.datetime is the
>>> largest module in Phobos, but I do think that comparing its line
>>> count to
>>> something like std.algorithm really tells you how much of a
>>> difference it
>>> makes in the size of the binary - especially when so much of it is
>>> unit
>>> tests which wouldn't end up in a binary.
>>
>> One thing is certain: someone who wants to take a look at
>> std.datetime
>> has the prospect of navigating 34KLOC.
>>
>>> The unit testing functions I wrote are pretty much in the same
>>> boat. They
>>> had thorough unit tests - testing not only all of its code paths
>>> (which
>>> is what the % code coverage gives you) but an appropriate range of
>>> values. The functions themselves weren't all that long.
>>
>> They are unrolled loops that should be rolled. Most likely they
>> test the
>> same thing several times.
>
> Some of them could be easily turned into loops - others not (most probably not).

There was not ONE I looked at that couldn't be reduced by using a loop.

>
> They don't generally quite test a set of consecutive values, though
> there is
> often a pattern to them.

They apply the same call to different values and check results. Loop.

> I tend to dislike doing much complicated just to try
> and reduce the lines in a unit test, because the risk of screwing it
> up goes up,
> and if the tests are wrong, the code will be wrong. So, the tests
> are simple but
> repetitive.

I don't buy this argument at all. What, are simple loops difficult all of a sudden? Then, one should strive to make all code simple; the argument is not for unittests only. The unittest scope is not a license to throw all good practices out the window and write bloat.

>
> The risk of screwing up like that for std.datetime is lower at this
> point, since
> it has already been thoroughly tested (the likelihood of a test
> failure when
> changing the tests is now much more likely to be a screwed up test
> rather than
> the code being broken). So, I'd be far more willing to try to alter
> the tests to
> take up less space now that I would have been when writing it.

Not buying this any more than the other. Good unittests are as goo as bulky unittests - in fact way better.

>
> I suppose that I could look at trying to turn some of the tests into
> arrays
> which get looped over. That sort of thing is not always going to be
> possible
> though, regardless of how repetitive the tests may seem.

I'd be hard pressed to find unittests tha are not, in fact, loops.

> And while the functions
> aren't generally long, and _most_ of them are simple, there _are_
> some of them
> with calculations which are easy to screw up, and a lot of tests are
> necessary
> to catch edge cases and the like. For instance, at one point, I
> thought that I'd
> finally gotten the gregorian day calculations right only to find
> that when I added
> tests for negative years which ended in 99, the result was always 1
> day off. I
> only caught it because I had a lot of tests.

Loops would have caught those too.

>
> While I'm fine with the tests as they are, obviously others aren't.
> So, I'll see
> if I can reasonably reduce how many lines they take up. But I'm not
> particularly
> willing to reduce what's being tested.

>

Jonathan, you are definitely right in principle. It's just the frightening proportions you are taking this to. Unittests are great. 10x unittests are not. I feel we cannot count here on some simple commonsense limits that would normally need no debate.

Andrei

On Friday 11 February 2011 00:50:08 Andrei Alexandrescu wrote:
> On Feb 11, 2011, at 12:24 AM, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Thursday, February 10, 2011 14:28:22 Andrei Alexandrescu wrote:
> >> On 2/10/11 11:33 AM, Jonathan M Davis wrote:
> >>> Well, as Steven says, most of std.datetime is unit tests. And
> >>> probably
> >>> over half of the rest is documentation, since most of the functions
> >>> themselves are relatively short and simple.
> >> 
> >> That means there are too many unit tests. There is such a thing as
> >> too
> >> much of a good thing.
> >> 
> >>> Add to that that I tend to like a fair bit of
> >>> vertical space in my  code (e.g. return statements pretty much
> >>> always
> >>> have a blank line above them), and how I code tends to take up a
> >>> fair
> >>> bit more LOC than you would without actually being more code.
> >> 
> >> As I mentioned, it would be courteous to your other colleagues if you were more economical with vertical space. Many people (and most of Phobos devs) consider vertical space a rare commodity.
> >> 
> >>> It wouldn't surprise me that if I
> >>> were to format std.algorithm in a manner that I'd typicall write
> >>> it, it
> >>> would at least double in line count simply due to additional blank
> >>> lines
> >>> that I'd introduce for code legibility.
> >> 
> >> I consider legible code compact code that I can keep on one screen
> >> and
> >> understand what it does.
> > 
> > There aren't very many functions in std.datetime which wouldn't fit
> > one one
> > screen. Regardless, it's obvious that code legibility is a
> > subjective thing.
> > 
> >>> And, of course, if I'd written std.algorithm, it
> >>> would almost certainly have had quite a few more unit tests. None
> >>> of that
> >>> increases the size of the actual binary.
> >> 
> >> It's not the size of the binary I'm worried about.
> >> 
> >>> I don't think that std.datetime is the
> >>> largest module in Phobos, but I do think that comparing its line
> >>> count to
> >>> something like std.algorithm really tells you how much of a
> >>> difference it
> >>> makes in the size of the binary - especially when so much of it is
> >>> unit
> >>> tests which wouldn't end up in a binary.
> >> 
> >> One thing is certain: someone who wants to take a look at
> >> std.datetime
> >> has the prospect of navigating 34KLOC.
> >> 
> >>> The unit testing functions I wrote are pretty much in the same
> >>> boat. They
> >>> had thorough unit tests - testing not only all of its code paths
> >>> (which
> >>> is what the % code coverage gives you) but an appropriate range of
> >>> values. The functions themselves weren't all that long.
> >> 
> >> They are unrolled loops that should be rolled. Most likely they
> >> test the
> >> same thing several times.
> > 
> > Some of them could be easily turned into loops - others not (most
> > probably not).
> 
> There was not ONE I looked at that couldn't be reduced by using a loop.

What I meant is that there are a lot of the tests which couldn't be turned into loops by incrementing the parameters. If you turn them into arrays of parameters to send to the same function, then yes, you can loop them.

> > They don't generally quite test a set of consecutive values, though
> > there is
> > often a pattern to them.
> 
> They apply the same call to different values and check results. Loop.
> 
> > I tend to dislike doing much complicated just to try
> > and reduce the lines in a unit test, because the risk of screwing it
> > up goes up,
> > and if the tests are wrong, the code will be wrong. So, the tests
> > are simple but
> > repetitive.
> 
> I don't buy this argument at all. What, are simple loops difficult all of a sudden? Then, one should strive to make all code simple; the argument is not for unittests only. The unittest scope is not a license to throw all good practices out the window and write bloat.

One of my key problems with using a loop in a unit test is that if you screw up the loop's body, _everything_ that that unit test is testing is incorrectly tested. Granted, if all you do is copy-paste the loop's body, you can run into the same problem, but by rewriting similar tests multiple times, such mistakes are more likely to be caught.

> > The risk of screwing up like that for std.datetime is lower at this
> > point, since
> > it has already been thoroughly tested (the likelihood of a test
> > failure when
> > changing the tests is now much more likely to be a screwed up test
> > rather than
> > the code being broken). So, I'd be far more willing to try to alter
> > the tests to
> > take up less space now that I would have been when writing it.
> 
> Not buying this any more than the other. Good unittests are as goo as bulky unittests - in fact way better.
> 
> > I suppose that I could look at trying to turn some of the tests into
> > arrays
> > which get looped over. That sort of thing is not always going to be
> > possible
> > though, regardless of how repetitive the tests may seem.
> 
> I'd be hard pressed to find unittests tha are not, in fact, loops.
> 
> > And while the functions
> > aren't generally long, and _most_ of them are simple, there _are_
> > some of them
> > with calculations which are easy to screw up, and a lot of tests are
> > necessary
> > to catch edge cases and the like. For instance, at one point, I
> > thought that I'd
> > finally gotten the gregorian day calculations right only to find
> > that when I added
> > tests for negative years which ended in 99, the result was always 1
> > day off. I
> > only caught it because I had a lot of tests.
> 
> Loops would have caught those too.
> 
> > While I'm fine with the tests as they are, obviously others aren't.
> > So, I'll see
> > if I can reasonably reduce how many lines they take up. But I'm not
> > particularly
> > willing to reduce what's being tested.
> 
> Jonathan, you are definitely right in principle. It's just the frightening proportions you are taking this to. Unittests are great. 10x unittests are not. I feel we cannot count here on some simple commonsense limits that would normally need no debate.

Well, I don't agree with you. I prefer to _avoid_ loops in unit test code and make it insanely simple. I think that that is less error-prone and that it leads to better unit testing code. I also prefer to have a lot of unit tests. I think that it has led to solid code in std.datetime.

However, I do acknoweldge that most people here disagree with me and think that the length of the unit tests in std.datetime is excessive and problematic. So, I will take time sometime relatively soon and work on making them take less space. And any future anything that I propose to Phobos, I will work on minimizing the amount of space that its unit tests take up before I propose it.

- Jonathan M Davis