Bad Code / Ugly Code

It has been unnerving to realize that my code is actually a good programmer's worst nightmare, but my stuff has always worked and my clients satisfied, so I never worried too much about it.

One thing I've heard Larry say many times is that it's okay to speak a subset of Perl at first. The same thing probably applies to program design. I, for one, learn as I make mistakes. I learn fast because I make mistakes fast and have been fortunate enough to catch and to fix most of them.

In the EE field, engineers fresh out of college have to have their work checked by a certified engineer. It takes something like four years to earn the certification. That kind of apprenticeship/oversight would be helpful for programmers -- but the barriers to entry to programming, especially in Perl and especially web stuff, are so low that anyone motivated to spend a week learning the basics and produce something that's reasonably useful for other people.

Those of us who have a bit more experience have a professional duty to help beginners improve their skills, replacing bad habits with good. And it doesn't stop.

There'll always be someone who knows more than me, and there will be times when someone else at or near my skill level catches something stupid or ineffective or dangerous. And some problems don't have a good solution, so the best you can do is find the least-bad option.

You have to maintain a minimum level of competence (and that level is high with security issues), but if your code works and you can maintain it, don't worry too much about how it looks. You'll improve the more you write.

Comment on Bad Code / Ugly Code

Replies are listed 'Best First'.
Re: Bad Code / Ugly Code by salvadors (Pilgrim) on Jan 02, 2001 at 00:11 UTC
if your code works and you can maintain it, don't worry too much about how it looks. You'll improve the more you write. As someone who's been really scared by some of the stuff he found today (perl coded I wrote circa 1994/5), I'll agree with this, especially if you're actively trying to improve all the time. One thing I'd say though, is leave yourself some comments. I looked at some of my 1994 code today and couldn't work out at all what it was meant to be doing! Aside: It's fascinating seeing how style has changed over this time too. And not just my style - perl style in general. In my perl directory were some scripts by TomC and Randal that just look so dated now. Yes, a lot of this was down to them being in Perl 4 rather than 5, but I think there's been a significant shift in what code looks like over time as well... On the other hand, I'd like to emphasise that this approach can only work when you are the only maintainer of the code. Code should always be developed with future maintainers in mind. If that's guaranteed to be you, then do whatever, but if it's likely to be someone else, then an entire different set of rules come into play. Then you're into good structure, proper comments, use (strict, warnings, taint), sensible variable names, documentation (good comments + "self documenting code" != documentation), even, dare I say it, testing! Fortunately Perl is a great language for all of these things! And luckily it's a great language for refactoring too, so if you're stuck with maintaining really bad code, it's easy to improve it a bit at a time. Have fun! Tony	[reply]

Replies are listed 'Best First'.

Re: Bad Code / Ugly Code
by salvadors (Pilgrim) on Jan 02, 2001 at 00:11 UTC

if your code works and you can maintain it, don't worry too much about how it looks. You'll improve the more you write.

As someone who's been really scared by some of the stuff he found today (perl coded I wrote circa 1994/5), I'll agree with this, especially if you're actively trying to improve all the time.

One thing I'd say though, is leave yourself some comments. I looked at some of my 1994 code today and couldn't work out at all what it was meant to be doing!

Aside: It's fascinating seeing how style has changed over this time too. And not just my style - perl style in general. In my perl directory were some scripts by TomC and Randal that just look so dated now. Yes, a lot of this was down to them being in Perl 4 rather than 5, but I think there's been a significant shift in what code looks like over time as well...

On the other hand, I'd like to emphasise that this approach can only work when *you* are the only maintainer of the code. Code should always be developed with future maintainers in mind. If that's guaranteed to be you, then do whatever, but if it's likely to be someone else, then an entire different set of rules come into play.

Then you're into good structure, proper comments, use (strict, warnings, taint), sensible variable names, documentation (good comments + "self documenting code" != documentation), even, dare I say it, testing!

Fortunately Perl is a great language for all of these things! And luckily it's a great language for refactoring too, so if you're stuck with maintaining really bad code, it's easy to improve it a bit at a time.

Have fun!

Tony

[reply]