Re: Perl Code Quality

I don't think you can sucessfully legislate code quality with a set of rules (especially not "must be OO", or "must be well documented"). Rules like that lead to OO solutions to non-OO problems, and documentation not worth the bits it is printed on.

Instead ask for code samples from the small company up front. And as YOUR code arrives, look at it. If you have time, perhaps you can write some of the source code comments or test cases, based only on the code you receive.

A second set of eyes is often the best path to clarity. The original author of the code is often too intimate with it to understand what the subsequent maintainers might find confusing.

I've maintained a lot of code. Far too often what the original author documented was already obvious to me based on the code. Usually I needed higher level hints -- like what the overall purpose of a code section is for. Or a description of the reason for a methodology or algorithm.

Comment on Re: Perl Code Quality

Replies are listed 'Best First'.
Re^2: Perl Code Quality by DrHyde (Prior) on Sep 27, 2004 at 09:25 UTC
Surely documentation that is "not worth the bits it is printed on" doesn't count as good documentation! Far too often what the original author documented was already obvious to me based on the code. Sounds like the difference between comments and documentation. Documentation tells you what the software does - the API, perhaps a high-level description of the algorithm. Documentation exists to help people who want to use your code (including other programmers) as well as maintainers. Comments are about how it does the job, and help explain much lower level stuff, eg "treat \ character as special", "these constants copied from MySQL headers", and are only for maintainers. Even so, they shouldn't say things like "add one to $i".	[reply]

Replies are listed 'Best First'.

Re^2: Perl Code Quality
by DrHyde (Prior) on Sep 27, 2004 at 09:25 UTC

Far too often what the original author documented was already obvious to me based on the code.

Sounds like the difference between comments and documentation. Documentation tells you *what* the software does - the API, perhaps a high-level description of the algorithm. Documentation exists to help people who want to use your code (including other programmers) as well as maintainers. Comments are about *how* it does the job, and help explain much lower level stuff, eg "treat \ character as special", "these constants copied from MySQL headers", and are only for maintainers. Even so, they shouldn't say things like "add one to $i".

[reply]