Re: Writing a large application in perl?

[jarich]

Do

• 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.

[cjf]

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 :).