Proposal for custom time string formatting in std.datetime

[Jacob Carlborg]

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