Alternately, getting rid of the global variables and repetition and encapsulating similar things in modules and subroutines — which can be named — might solve your problem.

Chunking up your code -- subroutines, modules, or best, objects -- let you encapsulate behavior. Instead of building a 3000 line monster, you build a toolkit of little safe, snap-in software components, then build these up into larger components.

Takes some investment to learn this style of coding, but Very Much Worth it. See for example, perlboot, or Damian's book.

When writing code this way, I often feel I am getting nothing done -- just building (and unit testing!) little safe easy functions.

I work and work and work, and nothing seems to be happening (except happy tests), then all of sudden the larger app stands up walks.

It is almost suprising to see it.

And it feels good to know you don't remember anymore how every tiny detail in the system works, but that is OK, you're safe,

• because you have your tests and
• because you've encapsulated and
• because you have well-defined APIs and
• because you have good variable names and method names, ala the refactoring folks.

Just my two cents.

rkg

It sounds like you are catching onto several different wavelengths.

Firstly, it sounds like you want an implementation of something akin to Knuth's literate programming

Secondly, it sounds like you want some kind of tagging mechanism, like ctags for example.

And thirdly, it sounds like you want an editor that lets you do this quickly and efficiently. If you haven't already had a look, may I recommend Vim

And while you're at it, and storing subroutine names/definitions etc, you could make it automagically fill in subroutine parameter skeletons.. Oh, wait, VB does that too :)

As the rest have said though, this is like closing the barn door after the horse has bolted. Don't attempt to fix your bad programming with a better way to keep track of it, fix the programming instead. If you have three arrays that need to be changed simultaneously (though that sounds as if it should be one structure, then), make a subroutine that does just that, and call it instead.

Lastly, no, I wouldnt want a spider that ignores robots.txt, its there for a purpose.

C.

There's OptiPerl which does something like that.

I only used the trial version for a while, it even looks up subs from modules and also shows objects properties and functions -- like VB ;) -- etc,

I'm still wondering if I should buy it or stick to gVim -- after all, it helped Marry.

---

He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

Chady | http://chady.net/

There's OptiPerl which does something like that.

The world does not need development tools that make bad code easier to write.

-- Rocco Caputo - rcaputo@pobox.com - poe.perl.org

Why not make it figure out which variable is defined where, and take you there when you click on the variable itself?

I thought of that, but I don't want to have people writing scripts that are only understandable when viewed by a special editor. My way, with comments for each instance of a variable, you'll never miss them. But if I added your feature, I'd probably have the variables for which there are global comments be a certain color, so maintainers wouldn't be clicking every variable, hunting for an explanation that isn't there.

The three arrays don't always have to be changed simultaneously, but they have to be kept the same length. If I add to one and decide I don't need the element, I only have to cut from one. If I used a tiny subroutine for that, it would have to compare lengths to see which arrays need to be spliced and if they're the same length, truncate all of them, else I'd have to pass the subroutine the arrays to truncate. Either way, it would take about as much code and be clearer if I duplicate the specific cut routine I need wherever I need it. Comments before each subroutine call would be a good idea too, so I wouldn't be eliminating any comments.

If I understand correctly, you want the ability to embed in comments named anchors and references to those anchors, so that clicking on one of the references automatically locates and displays the corresponding named anchor, right? It ought to be possible to extend cperl-mode to do this. You'd start by adding to the syntax tables the regexes and whatnot to recognize the comment-embedded references, and then you'd attach function in the cperl-mode hook that binds some key or mouse button to a function that checks the string properties at the point in question to see if it's in one of the references and if so does the appropriate thing (and if not passes through to whatever function cperl-mode normally binds to that keystroke or mouse button). If you want to do this, you should start with the Gnu Emacs Lisp Reference Manual.

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

If I ever have the time, I might look into customizing an open source editor to make it scroll to the part of the code that contains the label that's clicked in a comment.

Sounds like Exuberant Ctags, a program which produces a tag file that can be parsed by many editors. Admittedly, this requires the program to parse Perl code, which is always a problem. However, in this case, its better to have a partial solution than to have no solution at all.

A second to the "sounds like ctags" posts, and if you're an emacs user you might want to check out Hyperbole, which is a hypertext system which runs in most flavours of emacs and lets you define inter- and intrafile links.

If I understand correctly, you want the ability to embed in comments named anchors and references to those anchors, so that clicking on one of the references automatically locates and displays the corresponding named anchor, right?

Right. I guess I have a longer wait than I thought, since Elisp sounds like the way to do this, and I'd have to learn it. As long as it would also allow me to mark tabs on the scroll bar.

It's so large because it does most of this, though that interface is disabled and under construction. I have 11 subroutines in the script, and everything seems manageable, but a few times I had to look at parts that I hadn't seen for a while and I had to improve the comments. I'm new to programs this large, and I can't say for sure if I handled it the right way.

To some extent, the modularization is what's preventing me from doing all the work with a given variable at once, which is why I need numerous, identical comments in various parts of the script, to remind me of interdependencies of certain variables. For example, I have three arrays that each have to be spliced whenever one of them is, but that's not obvious when working on a routine that deals with only one of them. There are ways to automate that, but they are all more complicated than a simple comment that reminds me. It's essentially complete anyway, and I might be the only one to ever see the code.

And if anyone wants a free, experimental site map by a spider that currently ignores robots.txt, let me know.

For example, I have three arrays that each have to be spliced whenever one of them is, but that's not obvious when working on a routine that deals with only one of them

Use objects. Really. Your problem is that you are doing something complex and scurrying around doing all the things a good object system should be making simple manually all over the place. And as you have discovered, as a system grows large, it becomes impossible to keep all the details in your head at one time.

Step back from your code and analyze what it does. Massive use of global variables is usually a symptom of lack of analysis - you didn't know what you were going to do before you did it. In the hundreds of packages totaling megabytes of Perl code I've written in the last few years, there are only a few _dozen_ global variables - nearly all of which are in fact constants.

If you have three things that have to be maintained in complete synchronization - embed them in a 'container' object that understands how to update and read them. Talk to the container object - never directly to the hashes. Then updates only take one simple call and you worry about what not how the container does what it does in the rest of your code.

To some extent, the modularization is what's preventing me from doing all the work with a given variable at once, which is why I need numerous, identical comments in various parts of the script, to remind me of interdependencies of certain variables.

What? The whole idea of a properly modularized program is that you don't have as many interdependencies among variables or among different parts of the code.

What needs to be done, and which can be done without objects if desired, is to have the program separated by some opaque barriers and to group truly structured information into real data structures.



Christopher E. Stith

There seems to be three ways I could handle this.

• When I have to change a variable, check everything else that might require that variable to be changed and make all the changes in a relatively confined area. Only one comment on the use of the variable would be needed.
• Use subroutines for major divisions of the script and when they would make the script shorter, with comments to avoid problems with variable interdependencies. This is what I'm doing.
• Use subroutines or objects to avoid problems with variable interdependencies, in addition to subroutines for the major, parent divisions. This is what people are suggesting.

In my case, using comments rather than subroutines or objects for my array triplet (actually, I just realized it's a quadruplet) avoids problems with variable interdependencies just as well. It also makes my code easier to follow and understand, run faster, and easier to develop (especially for me).

Yesterday, I forgot which of those arrays had been added to by a certain point in the script, and I wanted to splice those that were added to. Rather than permanently using a splicing routine that checks the length of the arrays, I used such a routine as a debugging tool only, found out which arrays had been added to by that point, then permanently added lines to splice only the arrays that would need splicing at that point. In addition to preventing having to dig deeper into the code to understand it, my unconditional splicing makes apparent which arrays had been assigned to by that point in the code, which could be useful for future maintenance.

If your on Windows, try Homesite its not just for HTML, it has many nice code navigation features (bookmarks i think they call them). It also does a good job on syntax coloring for Perl. Additionally it has other features such as code snippets that can be tied to command key combinations, etc. Its been a version or 2 since i last used it heavily, but all the other programmers at work use it and swear by it.

If your on Mac OS X, try Project Builder, its part of the starndard Developer Tools (although I think XCode is replacing it, you can still download the old one though I'm sure). It has a number of features; you can split the current editor window into 2 panes, and scroll them independently; you can easily code and run perl script marcos from the current selection (which could launch browsers and such); you can substitute the normal "build" shell script with your own to perform just about anything you need it to do. It integrates nicely with the CVS installed with the Apple Developer Tools.

Any other platform, your on your own.

I will refrain from commenting on your coding style, and just say that i agree with chromatic and rkg.

DZSoft's editor will list all your variables and subroutines in a left hand column and I believe you can "bookmark" up to 10 spots in your code.

Hope that helps!

It can make a hyper-linked list of all places where the word you searched for was found. Id for subroutines.

The macro-function probably allows you to automate this (just select the word and create the list at the push of a button).