• Do use CGI, or CGI::Simple.
• Do use strict and warnings and CGI::Carp from the start.
• Do use templates (HTML::Template or Template::Toolkit)
• Do write yourself a requirements list if possible.
• Do design the whole thing before you start
  • what administration pages will you need?
  • what sequence of events will customers follow?
• Do create your test cases and scaffolding before you start.
• Do make paper webpage mockups and walk through the client process with a non-geek, perhaps your father?
• Do try to identify all the code you can dump into separate libraries
• Do consider OO where it might be useful.
• Do search CPAN, freshmeat and sourceforge to see if your system or parts of it have already been done before.
• Do ask here to see if we know where it's been done before.
• Do use CPAN modules to do the parts of your project that they can.
• Do make sure that the modules you choose to use are well supported and suit the task you're using them for.
• Do use taint checking. Lots. Always.
• Do expect to throw parts away once you've found a better solution
• Do throw away parts when you've found a better solution
• Do use DBI and its friends if it's DB related
• Do investigate the pros and cons of different databases before starting
• Do read about useability and try to design your system to be useable by a large range of skill levels and disabilities.
• Do think about open-sourcing the end result if you're happy with it.
• Do comment it thoroughly
• Do be consistent in your coding style - and please use one that is considered "standard" (K&R, GNU or another)
• Do try to keep each subroutine less than two screenfuls (ie less than 50 lines) because even if you don't succeed it's a good metric.
• Do try to refactor as much as possible, whenever possible so that your library code grows faster than your scripts do.
• Do test and test and test again. And get someone else to test too.
• Do use a decent change management system such as CVS. Use it properly and tag releases (where it compiles, works and is stable (though not necessarily complete)).
• Do document your module/function interfaces and keep these documents up to date.

Don'ts

• Don't expect it to be easy
• Don't skim on requirements or design
• Don't reinvent the wheel just for the hell of it
• Don't refuse constructive criticism
• Don't write ugly code and then beg us to fix it for you :)
• Don't give up, large projects are a great way to improve at your chosen language.
• Don't use global variables unless you absolutely need to, in fact, don't use them then either.
• Don't hardcode in URLs, filenames, HTML headers, magic numbers. Try to move these to a good localisation module.
• Don't turn strict off. If you need to turn it off, you're probably trying to do something a wrong way.
• Don't keep code just because it took you ages to write it. When you've found a much more elegant/efficient/effective solution, fix your code.
• Don't spend all your time worrying about finding the absolute best way to do something. Do it any way the first time and come back and rewrite at your leisure.

Update:A few more don'ts.

Excellent list, you forgot one Don't though:

• Don't forget why you're working on the project. Learn as much as you can, make it fun, and hopefully end up with something useful.

Also, to expand on the open source part, consider trying to get other's involved in the project, you never know what it might evolve into :).

As for code legibility, perltidy gives a good example, and both perlstyle and Tom C's style guide have good advice.

How much OO? It's impossible to give a very useful general answer. Enough to give good abstraction, but not so much that you spend a lot of time thinking about the OO constructs rather than the problem you're trying to solve.

Here are a couple nodes that may be of interest:

• Starting a Large Project
• Good book on programming large CGI applications?

Best of luck :).

Folks have given you good advice above, to which I'll add this: Once a project gets past the point where you can expect to have most of the team members keep the code live in their heads, you'll need a set of diagrams to describe the system. These diagrams can be simple (say, a few UML object diagrams, plus some key sequence diagrams, plus any key state charts). Any more than you can post on the side of a cubicle is too much, in my experience.

Having a set of diagrams makes it a lot easier to bring someone new up to speed, especially with a large code base. Having a few good diagrams also streamlines design sessions. If you're in disagreement, at least you'll know that you're disagreeing about the same thing.

Excellent suggestion.

Having some kind of diagram/flowchart will be a lifesaver a few months down the road. No matter how straightforward it seems when you write it you will forget things later. It will also save someone elses sanity when they jump in to help.

mr greywolf

Keep the modules separated enough that they don't need to know so much about each other (this is de-coupling). They should only talk to each other using well defined interfaces (this is data hiding). Doing this will make it possble to keep it "small enough" in each module and the overall complexity low by not having to know the big picture everywhere.

Something you actually (hopefully :) did but maybe never thought about when scripting is analysis and design. These have to become more explicit when developing larger applications. You have to take a step back and get an idea of the structure of your application, what subsystems and modules it consists of and how they tie together.

You have to document this somehow and communicate it to other people, maybe fellow programmers, maybe sysadmins, maybe a project leader, maybe yourself six months from now. Pictures are good. Good writing is good.

When the script grows, things that can go wrong add up. Depending on your application, it may need to log things for debugging purposes, and more importantly for outright errors. When things go wrong, abort early, log what happened and notify the programmers (that would be you) by email. This way you'll know when, in your production environment, things didn't work out as planned. This will happen. Promise. Sorry :)

/J

Plan a design before you start. What objects will you need? What will each object do? Use pod to document your code as you go along. Plan to throw away at least one design and start over. You will probably get started coding and realize that the design you thought was so nice inherently makes a needed feature very difficult, or some other fatal problem will arise, it's happened to me. Experience will help with this.

TGI says moo

Plan a design before you start.[...] Plan to throw away at least one design and start over.

Try to keep your design fairly compartmentalized, and loosely coupled. That way, when you do find a flaw in your first design, you don't have to throw everything away: some of the code you've already written will easily work with your new code. (For instance, if you're always updating a database the same way, and you keep the database update code well-separated from everything else, you won't need to make any changes to it when you realize that your interface code is hopelessly screwed, trash it, and start over.)

--
The hell with paco, vote for Erudil!
:wq