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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
