Re: Re: Re: Sub-initiate needs help getting started

But go ahead guys. Keep on declaring any code that does not meet your personal standards for cleanliness or elegance to be "worthless" and watch the number of IT managers who refuse to let Perl anywhere near their shop grow.

The desire to rewrite rather than modify is not limited to perl programmers.

Shit code is shit code. Good code is good code. I know. I've written both. And one of the main differences is that when it comes time to make changes and add features, the shit code is sheer agony and the good code is surprisingly easy.

If the new reports are only trivially different from the existing reports, the OP might be able to tweak the program to meet the needs. Some parts of the program may be salvagable.

But a system that is contained within one 8000 line file with few or no comments, doc, no warnings and no strict, and lots of global variables named in the form g_xxx is almost certain to be shit code. It is hard to imagine anyone who cared writing anything decent that matched this description.

But it probably is a mistake to condemn it without seeing it. Lori, you might want to try and get some help with this. This is one place. Another might be at a meeting of your local Perl Mongers group. http://pm.org.

The advice given above about learning how your webserver works is excellent, especially the log files, especially the error logs because anything you output to STDERR (eg warn 'something') ends up there instead of in the webpage.

--Bob Niederman, http://bob-n.com

All code given here is UNTESTED unless otherwise stated.

Comment on Re: Re: Re: Sub-initiate needs help getting started Download Code

Replies are listed 'Best First'.

Re: Re: Re: Re: Sub-initiate needs help getting started
by agentv (Friar) on Aug 28, 2003 at 05:18 UTC

...I'm inclined to agree mostly with this. But I still consider it to be mostly superficial evidence. In aggregate, I'd expect it to be a code base of which I'd be wary myself, but from just the facts we have, it could be that the code is well written enough that comments would be superficial (the chances are slim, but it's possible), and that it's laid out well enough to provide its own documentation. I can certainly write code that well, and I know that many of you think that you can too.

The use of -w and strict was not nearly so universally expected as recently as 5 years ago. And I'd be willing to be that this code has evolved over a fair amount of time. This doesn't sound like a two-month hack. (Unfortunately, it sounds more like a 4 or 5 year hack.)

The 8000 line thing looks pretty grim to me, but my reaction to the global variable thing was to say to myself, "Good, at least he used a naming convention for those."

But here's my main point. I believe in clean, readable code every bit as much as the next person. In fact, I proclaim whenever I teach, that "Vinny's Second Law of Programming" is "Thou shalt make it readable!"

Inevitably this invites the question, "The what is the first law?" To this I reply, "The most elegant code is the code that's finished."

So if given the choice of working with a body of code that is not to my taste, or rebuilding everything from scratch, I will choose to use the existing code unless it is truly impossible. The more competent I am, the more broken the target code can be for me still to succeed.

Given the stated time parameters for this problem, rebuilding from scratch does not seem to be an option at all. On the other hand, assimilating horrid obfuscated navel-lint code doesn't seem to be a great option either. But there's no reason to despair yet.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

[reply]