reidlos65 has asked for the wisdom of the Perl Monks concerning the following question:

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re: Removing unessary data
by marto (Cardinal) on Jul 21, 2011 at 13:40 UTC

    With all due respect you've simply posted a sepc of what you've been told to produce, and a reasonably well documented script which does something very similar. Perhaps you should see this as the learning exercise it's clearly intended to be rather than just ask someone else to do it for you.

    As far as learning Perl goes:

    If you have any specific questions or problems please let us know.

        Perhaps, though that could simply mean the they need to be able to read and understand the code and the comments provided in order to find out what can be removed and what needs to be changed :)

        Update: Wrinting their own script seems to be out of the question

      Yes I figured that's what it would come to seem, it wasn't intended as that however, I am not a scriptwriter, nor does my job require me to do/learn it. It is a side project that doesn't have alot of time for it. This is like giving me a short story in German, and asking to spell check it for me. (I don't know German) I was asking more of at least the best way to weed out the large amount of unneeded code.

        If you have no incentive to learn Perl, or how to read the comments and work out which parts aren't needed to complete the task you've been given, perhaps it's best to tell the person who assigned you this task that you don't "have alot of time for it" and that you're "not a scriptwriter, nor does my job require me to do/learn it". It's pretty well commented, it's pretty much all done for you, there's no real short cut.

        Writing a script on your own to achieve this task will be out of the question if you refuse to learn how to use the tools required to do the job.

        Update: s/insentive/incentive/ thanks toolic

Re: Removing unessary data
by chrestomanci (Priest) on Jul 21, 2011 at 15:00 UTC

    Why do you want to remove unneeded code? what harm is it doing you?

    A wise programer might answer that it hurts performance or my contain bugs that harm overall stability, but seeing as you have no desire to learn perl, you are not in a positon to fix bugs or performance issues, and removing code you don't understand more likey to break the program than help it, so my advice is not to edit the code any more than you have to.

    Having said that, if you realy want to know what parts of the code are not used, My advice would be to use a coverage or profing tool such as Devel::Cover or Devel::NYTProf to tell you which parts of the code are not touched during a typical run of the program.

      I not unwilling to learn, I have just a situation where im being asked to do something I dont know how to do, using a very advanced script that does several intertwined unnecessary actions. I wanted to see if it could be broken down to a set of information as to what needs to be removed. Thanks

        "I wanted to see if it could be broken down to a set of information as to what needs to be removed."

        Again, that's what the comments are for, they tell you what the associated parts of the code do.

        im being asked to do something I dont know how to do

        In situations like these I tell the one who asked me, that I'm currently feeling unable to solve the task but that I'm willing to try. I will also tell him that I will not be able yet to tell him how much time I need.

        In regards to the script: Use the source young jedi! Comments are a powerful part of the source. And then there is always perl -d...

        May the source be with you ;)


        s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
        +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
Re: Removing unessary data
by locked_user sundialsvc4 (Abbot) on Jul 21, 2011 at 14:51 UTC

    After ... please, please, please ... this posting has been edited to use code-tags and other tags as spelled out in “Markup in the Monastery” ....

    ... I approach problems like this one by further breaking-down the code into individual subroutines which are called by higher-level code in a meaningful way.   I also try to encapsulate, to eliminate if possible, and in any case to isolate, global variables.   I want the “visibility” of data is as compartmentalized as possible.

    But you also need to start, from the very beginning, by constructing test cases which will represent the actual behavior of this module so that you can run both the original version and the rewritten version in parallel and objectively demonstrate that they are functionally identical.   You need to do the entire effort using a version-control system (such as git, which doesn’t require any server), because you need to carefully document each change and to be able to reliably restore the system to any prior state.   (You also need to be able to “experiment,” which branches allow you to do, and to “tag” specific revisions that have or have not passed the suite of validation tests.)

    One thing that is working in your favor in this case is the fact that the existing code appears to be very well documented.   I suggest that you should, before you start the reconstruction process, build a project-plan for yourself, and follow it.   Keep a daily “running log,” or diary, and keep it scrupulously up to date.