|
in reply to Some of use just want to know the basics
- Is it just a matter of programming self-confidence, to be able to say "this is finished and correct", without a uneasy sense that there may possibly still be a mistake somewhere.
No. I have found that a program is only finished when it is no longer being used, and that it is never truly "correct" in the sense that it is the best way to do it. TIMTOWTDI is more then just a slogan, its a reality. The result is that as you learn more techniques your view on what is "correct" will change. As for "correct" in terms of being bug free, self confidence is not the same as sufficient testing. And neither is ever enough to avoid all bugs. A solid design and a deep understanding of all the potential problems will put you on the right path, but there will always be bugs. The trick is keep the bug count low. (Unless you work for NASA, in which case the trick is to keep the bug count == 0, but they devote more time to design then some companies spend doing an entire life cycle.)
- What would you advice a "I just want to apply the basics correctly" type of monk like me?
Time for the Nike slogan: "Just do it." The best way to learn to use Perl, is to use Perl. Define your problems and write code to solve those problems.
- What are the inherent dangers of cut and paste programming?
Many. The worst danger is that you inherit some one else's bugs. Other dangers include the fact that if you lack an understanding of the code then it makes it impossible to maintain. Never use code that you don't understand. This is, as others have said, different from using third party solutions or modules.
|
