in reply to Re: Is too little too much? Coding under the microscope...
in thread Is too little too much? Coding under the microscope...

  • "Programming means making trade offs. Ideally, code should be correct ... , fast, resource friendly, 4with a5small memory footprint, 4using a5 small amount of code, easy to maintain, 4and5 easy to understand"

    • All of this is good and logical. Im not new to programming, just programming in Perl. I admit, however, I do ignore a lot of things or rather take many things for granted when coding simply because I <admittance type=shameful>assume</admittance> that shorter code is quicker and less resource munching.
    Perhaps there is a quick way to take a script and push it through some kind of perl module or perl-builtin function that can monitor the resources during runtime and spit out the resources used during that runtime. I know we have the benchmark module but admittedly I know next to nothing about what all it can do and how it can be used to monitor whole scripts (if indeed it can do so). And what I do know about it I have learned here on PerlMonks. It seems to be best used for finite benchmarking of code within a script and not the script itself. I will look at the documentation for benchmark more closely this evening when I have time to. It seems a little unreasonable and very time consuming, though not necessarily ridiculous, to benchmark every questionable block of code in a script.

    Imo, understandability is perhaps the single most important thing when programming. Even if this means extensive documentation in the code to walk someone ** through your code. Is it just me, though? Perhaps I am just catching on to this, but short complex code -eq obfuscated code? But this is exactly my question. Why would the Perl developers make it possible to write tight liners (heh, thats what I call em) if it wasn't something that wasn't ''good''. I understand that it is most likely not always a good thing as not everything can always be good, but two things come to mind regarding this kind of code:

  • 1. A tight liner is easier to write (less to type) and seems like it would be more efficient.
  • 2. The operation of a tight liner doesn't seem like it would operationally be too much different from writing it out into blocks (see my first examples).

    • I am kind of playing the devil's advocate here. In doing so I am just trying to see if I can relate to both sides of the spectrum of this kind of code being good and/or bad.

    **  including yourself...yeah, we've all been down that road before where we look at something we wrote a year ago and wonder..."What on Earth was I thinking when I wrote this?"

    ----------
    - Jim

    • Comment on Re: Re: Is too little too much? Coding under the microscope...

    Replies are listed 'Best First'.
    Re: Is too little too much? Coding under the microscope...
    by bikeNomad (Priest) on Jun 29, 2001 at 02:39 UTC
      Why spend a lot of time worrying about efficiency as you're writing the code? Do you know that your program is slow? Is it too slow? Why worry about small gains in efficiency before it runs correctly? For that matter, how could you know that it needs speeding up until it works?

      Once you have it running right, and you've decided that it needs speeding up, then you can apply a tool like Devel::DProf or Devel::SmallProf to find and fix the "hot spots". But it's unlikely that shortening two lines that get called once into one line is going to make enough difference to make it worth while agonizing about it up front.

    		[reply]

    In Section Seekers of Perl Wisdom