On Apr 21, 2004, at 4:16 AM, Michael C. Davis wrote: [..]
Thanks for the insights, drieux. While I wish I were in a position to establish corporate policy, I'm not, and my objective is merely to satisfy myself that I have a reasoned, workable approach. Your feedback helps a lot.
Coming up with a 'coding standard' in any language can be the first step on the road into the abyss. If it really helps with creating Clean API's then it is a good thing. If it becomes an excuse to merely 'refactor code' so that all of the curly braces are in compliance with a standard - rent a life, buying one may be too expensive at this point.
But since one has started to see the merit of having a 'stock way' of seeing easily and quickly that some 'token' should be a [ constant | local_var | global_var | method | Module | briefPsychoticInterlude ] then it will make cutting the API's simpler - as everyone will use the same 'reading skills'.
At which point one, in Perl, has already figured out that managing their Perl Modules is the simplest and cheapest way to 're-use code'.
At which point it really is time to work on the whole t/ Test::Harness way of documenting and validating that the Module is Good. And that the POD is truthful and honest.
I was explaining the transition from using Perl's t/ strategy and porting it over to doing c-code and that saved us a bunch when we did the 32-bit to 64-bit cut over - because the obvious dumbs, and with them the core dumping in that t/ stopped when we had cleaned up the places where we wanted a u32int vice a 64-bit int... At which point we were ready to step forward and do the basic dynamic testing, and all was good with the world. When I chatted about this with the Freak who converted me to Perl, he noted:
"oh no, I am a bit harsher. If the code does not
come with a 'make test' - then I want your pager
number, and you will be in my office within 15 minutes
and YOU will be bringing the Chocolates..."Where this whole 't/' static testing saves one in the long run is that it will allow one to grow out the suite of basic tests over time as one has those ParaNoidDelusional moments that says:
"but what if a code monkey did foo???"
and if one builds the test, and it breaks your Module, then you needed to fix that anyway - and the test is still there in the t/ and the code is better...
So in classical Trinitarianism it is:
Phase I: Master Yourself
Phase II: Collect Underlings
Phase III: Global Domination!!!
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
