| [reply] |
Perl::Critic is very, very useful if you want to enforce coding standards, or want to start refactoring some "bad" coding practices out of a project.
That said, it's really only going to catch syntactic and stylistic problems, though. It won't help you find forgotten filehandles, silly program logic, terrible variable names, or other problems inherent in bad legacy code.
| [reply] |
use strict; use warnings; are your best friends for that sort of thing.
After that making sure that you use good names for things (var1 is a bad name BTW :) and a clear and consistent indentation style helps a lot.
Where there is something that will do work for you, use it. That is, use modules, they save reinventing wheels and are likely to have been fairly well debugged - especially if they are popular.
DWIM is Perl's answer to Gödel
| [reply]
[d/l] |
those code are written by a group other people. so I need to do some analysis and
it is very hard for me to go thru those lines one by one.
I have do the use strict and use warnings and found somthing, and just wonder if
there is anything more/suggestion that people have used???
thanks
| [reply] |
Not strict-ly a syntax checker (HAH! I kill me!</ALF>) but perltidy can help get a hairy codebase into a more readable form.
| [reply]
[d/l] |
See also B::Lint. I'll be giving a short presentation at Minneapolis.pm on Wed Dec 14 2005 about extending B::Lint to cover new warnings.
| [reply] |
| [reply] |