The thing about enterprise software is that it has to work, and should fail as gracefully as possible. Historically Perl is described as a swiss army chainsaw, highly versatile but distressingly inelegant, and was used as an automation language.
He argues(!?) that unquestionably,
- We should be writing object orientated code
- You shouldn't repeat yourself (copy & paste is bad)
- Cargo cult programming is bad
- Use small or one concept methods
- Contents of loop should be a method call
- Constant should only appear in one place (common blocks?)
- Config files are bad things (really?)
- Logging should be at an appropriate granularity
More contraversially, we should all be using proper exception handling,
sub UNVIERSAL::exceptipn {
my $class = shift;
no strict refs;
@{$class . '::ISA' } = qw ( Error );
}
exception Foo;
and also,
- Object orientated programing is about message passing
- Data driven development is bad (use mechanisms)
- State is a bad thing (creates tightly bound components)
- But being stateless is a bad thing (implied knowledge)
- Strike a balance between state and stateless-ness
- Don't hardwire class names (why?)
- Don't use arguements to constructors (really!?)
- Better to call methods (what about overhead!)
- Use method chaining to replace constructors (return
$self) - Recompose types, subclassing in Perl is poor, so use
tie'ing - Recompose builtins, better as methods (eek!)
- Objects are rarely true as a result of constructing it
- Conditionals are bad (confuses method names?)
- Use value singletons and compare references
Some of which I agree with, and alot of which I don't...
Finally he argues that as a programmer you should ask who you're talking to, you aren't talking to a computer (we'd be writing in assembler), instead you're writing for other programmers.
