On Feb 11, 2011, at 12:00 AM, Steve Schveighoffer
<[email protected]> wrote:
----- Original Message -----
From:Andrei Alexandrescu <[email protected]>
On 2/10/11 9:50 AM, Steve Schveighoffer wrote:
----- Original Message -----
From:Andrei Alexandrescu<[email protected]>
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 don't think so, but I cannot be sure. I'd say a full 75-90% of
std.datetime is unit tests or documentation. That shouldn't
increase
the size of the lib, and certainly not by as much as it does.
It increases the size of the source that someone looking at the
library must
navigate and absorb.
In case I wasn't clear: my concern is source size. I am now sorry I
mentioned library size, and twice so because I didn't verify the
hypothesis.
OK, source size. But still, the "relevant" source size is small.
All code is relevant.
The unit test source size is large, but who's reading all the unit
tests?
People who look at the file.
Won't people skip over those?
Skipping is overhead, particularly when relevant content is drowned in
a sea of chaff.
It is difficult to believe that a library needs that much unittests
in terms of
sheer size. The more I browse through std.datetime, the more firmly
my hair is
standing up on my head. It's most all large hand-unrolled loops. I
am now
sorry I voted for the library without having raised a flag at this
very serious
problem. I didn't realize its size back then.
I guess I just don't see it as a problem. Source *size* doesn't
concern me, quality does.
This goes without saying.
As for the amount of unittests, I feel like it's up to the developer
to provide unit tests, and if he/she prefers to provide extra unit
tests, that's fine.
Honest, I felt the same but datetime proved me exaggeration is harmful.
I think the number of unit tests should be greater than 0, no upper
limit.
Again I used to think the same. I've since recanted.
And my unit tests are usually not looped because unit test failures
usually give you a line that failed. If you loop them, then you're
not sure what loop iteration failed.
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.
Lines of file does not mean % of a library, especially when a large
portion of it is not compiled. I think we need to stop this
prejudice against uncompiled LOC. I fully support having unit tests
next to the code being tested, it's the whole point of the builtin
unit test system in D.
I am sorry, I disagree with discounting LOC. LOC is LOC. Compiled
or uncompiled
it is intellectual overhead. We need to write good code, code that
we provide as
living examples on how to write quality programs. Good code is not
unrolled
loops. Well, except sometimes :o).
Sorry to also disagree :) Veritcal space isn't code, documentation
is not code, unit tests are code, but only relevant if you are
reviewing unit tests.
Vertical space is informational real estate.
LOC to me is the code that you have to read to understand how the
library works.
LOC is loc, period.
unit tests don't qualify.
Most editors have folding ability or an ability to skip to the
matching bracket.
Structured editors are definitely helpful. I don't want to /require/
one for viewing phobos.
This makes it irrelevant how many lines a unit tests occupies if
you are skipping over it.
It is relevant to anyone not using an editor especially designed for d.
And if you aren't reviewing the library, you just want the API, you
should be using the generated docs, which have nothing to do with LOC
Agreed. Again, Phobos sources will be studied and emulated by many. I
don't want d to earn the reputation of a language requiring ten
unittest lines per payload line.
-Steve
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
