On 2011-12-22 12:27, Jonathan M Davis wrote:
On Thursday, December 22, 2011 12:01:31 Somedude wrote:
Le 22/12/2011 11:40, Jacob Carlborg a écrit :
Yeah, I don't get this. Most modules in Phobos are too large, in my
opinion.
It largely is a matter of taste, I think. There are advantages in
minimizing the size of files but there are also advantages in minimizing
the number of files.
But for datetime.d, it has largely gone beyond my own point of
acceptability (which is about 5,000 lines, if that means anything).
Well, a large portion of the file is documentation and unit tests, and the
number of lines that the unit tests take up should go down as I refactor them
(which I've done some of, but I've still got a long way to go), but it's never
going to be anywhere near as small as 5,000 lines. SysTime alone is over 5,000
lines (though again, much of that is documentation and unit tests). But
ultimately, I think that whether a module is too large or not is a function of
its API rather than the amount of source code. It's a question of how
digestible the documentation is. And by that count, std.datetime is still
quite large, but it's a very different measurement.
- Jonathan M Davis
Even if you cut it in half I think it's way too large. I think 5000
lines are too large as well.
I don't agree with what you're saying about the API. If a module has 5+k
lines and only one public function and the rest are private functions I
will still think it's too large.
About the unit tests. If they take up so much of the module then move
them it their own module(s). And now everyone will say that it's very
useful to have the unit tests next to the function. I don't agree with
that when the unit test is more then around five lines.
I will have the same problem with std.serialization/Orange if that will
end up in Phobos. In Orange I'm testing one feature in one module and
all modules are located in a specific directory. The shortest testing
module is 54 lines. The average is probably around 70 lines. I'm not
particular happy about putting all those tests in one file and even less
happy about putting them next to all the regular code making those
module EVEN large.
You should treat your testing code just as you treat your "regular"
code. Just as well designed, just as modularized, just as effective,
just as clean. The testing code is in fact just as much part of the
"regular" code as the rest of the code.
--
/Jacob Carlborg
