Beefy Boxes and Bandwidth Generously Provided by pair Networks BBQ
There's more than one way to do things
 
PerlMonks  

Re: Re: Worst thing you ever made with Perl

by trs80 (Priest)
on Sep 28, 2003 at 18:28 UTC ( #294782=note: print w/ replies, xml ) Need Help??


in reply to Re: Worst thing you ever made with Perl
in thread Worst thing you ever made with Perl

I am glad you are strict enough with yourself to follow your formal training. However for the many people out there I imagine it is hard to stick with The Right Way(tm) to do it when faced with time-line pressures or simply laziness. While the benefits of doing it The Right Way(tm) far out weigh the initial time invested that doesn't make it any easier to stick to it. Adopting a mind set of
"How will this effect me X days from now?"
"When I revisit this code in X (days|weeks|years) will I remember that I was thinking?"
"Will someone else find this to be The Right Way(tm) and if so why?"
then we can help ourselves to improve. For those of us that aren't blessed with strictness we can only hope that over time we stay commited to refining our process until our actions follow The Right Way(tm) without being forced.


Comment on Re: Re: Worst thing you ever made with Perl
Re: Worst thing you ever made with Perl
by Abigail-II (Bishop) on Sep 28, 2003 at 23:04 UTC
    However for the many people out there I imagine it is hard to stick with The Right Way(tm) to do it when faced with time-line pressures or simply laziness. While the benefits of doing it The Right Way(tm) far out weigh the initial time invested that doesn't make it any easier to stick to it.

    I fail to see how deviating from "the right way" would mean you program faster. Does it really save time not to do proper indentation? (If you set ':set ai' in vi, most of the work is done for you anyway). Do you save significant time not using properly scoped variables? Saving time using symbolic references is something I find hard to believe. I'm not taking any future consideration into account, I'm talking about programming right now, with a 5 pm deadline.

    Abigail

      Good practices that take more time:

      • Writing tests. Either after the code, or doing TDD.
      • Proper modularization of code. It's faster to just throw together procedural code than create a new module.
      • Documentation. Everything from proper comments to user docs takes time to write.
      • Quality assurance of third-party modules. Grabbing something off cpan and assuming it works is a lot faster (short-term) than testing it.

      Those are what immediately come to mind. There are plenty more. As for your points: indentation takes no time so no excuses there but many times global variables can speed things up development (think instead of passing args and returning values from subs) this is however a very tricky process and rarely (but still sometimes) the best approach.

      The Right Way(tm) elements are far more then just indenting , improperly scoped varibales, etc.
      Elements central to the ideas behind my original point are:
      • The initial time it takes to learn what The Right Way(tm) is
      • Remembering and applying The Right Way(tm)
      • Fully understanding concepts and the ramifications of not doing it The Right Way(tm), before you move the knowledge from the mind (private space) to the physical (public space)
      This goes beyond programming and extends into any discipline. However, the shared realtiy of life is that the above does not work because if we all remained inactive until we comprehended then we would remain inactive. We must crawl, walk, run.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://294782]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (21)
As of 2014-04-18 18:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (471 votes), past polls