[EMAIL PROTECTED] wrote:
> Thanks, all.
>
> Good to know no one's been beheaded.
>
> Yes to separating test and non-test code, but no if that will just
> turn one modest module into two modules, smaller still.
>
> Amen to 'practicality beats purity.'
>
> Do wish we had a good, thorough conventi
Thanks, all.
Good to know no one's been beheaded.
Yes to separating test and non-test code, but no if that will just
turn one modest module into two modules, smaller still.
Amen to 'practicality beats purity.'
Do wish we had a good, thorough convention set. I wrote one for Java.
It took a lot o
Ben Finney wrote:
> [EMAIL PROTECTED] writes:
>
>> By convention, I've read, your module begins with its import
>> statements. Is this always sensible?
>
> There are exceptions, but the benefits are great: It's very easy to
> see what this module requires, without needing to execute it.
>
>> I p
[EMAIL PROTECTED] writes:
> By convention, I've read, your module begins with its import
> statements. Is this always sensible?
There are exceptions, but the benefits are great: It's very easy to
see what this module requires, without needing to execute it.
> I put imports that are needed for te
[EMAIL PROTECTED] wrote:
> By convention, I've read, your module begins with its import
> statements. Is this always sensible?
>
> I put imports that are needed for testing in the test code at the end
> of the module. If only a bit of the module has a visual interface, why
> pollute the global na
[EMAIL PROTECTED] wrote:
> By convention, I've read, your module begins with its import
> statements. Is this always sensible?
>
> I put imports that are needed for testing in the test code at the end
> of the module. If only a bit of the module has a visual interface, why
> pollute the global nam
