P is for Practical | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
First, thank you for your constructive input. It is really appreciated. Now, to give you a little perspective, the firm I work for does not hire minimum waged developpers, and it's not about trying to manage newbies. In fact, it is so hard to find experienced Perl developpers that the firm hire C++ or Java developpers and train them to Perl. I'm not even kidding. I am not saying everyone being hired is forced to work in Perl, but the group I work with mostly do Perl development, some other groups also use Perl, C++ and/or Java. In my group, we support old applications but we also build new ones, in Perl. On our systems, not only we have access to all the (approved by the firm) CPAN modules but we have access to all the versions of these modules, build for all version of Perl from 5.8, 5.10, 5.14, in 32 and 64-bits. So, the best practices I am trying to compile is of course to improve the readability of the code, because it is certain that multiple programmers will work on it, but most importantly, it is a tool for less experienced developpers to avoid pitfalls that could lead to hours of debugging weird issues. Note that we have dozens of different projects, all object oriented, some uses Moose and MooseX syntax, and several projects share dependencies with each others. It is serious stuff we are doing. With that said, I will add some explainations on the selection of the best practices you are debating. 3: You are right, it is as easily readable but at some point we need to choose one or the other. I hate to see two different styles in the same file. I like the way I mentionned because it adds a natural empty line, and it answers your recommandation: Use white space to make your code easy to follow. 4: This one I added last to my list. I am not sure about it. 5, 6, 7: This is mostly for consistency, since we have multiple developpers working on the same projects. It is debatable, I agree. 9, 10: These are not about readability. In our experience it may lead to very weird problems. We use a lot of callback functions and we often use classes that extend other classes. This one doesn't come from me but it was already in place before I started working here. 11, 12: This is for readability. You are right, I will merge them. 13: OK I will try to re-state the narrative. Got this one from Perl Best Practices. For the rest, of course we use strict and warnings. It is so obvious to me that I forgot to add it! Indent, break, empty lines, white spaces, etc. I think this is obvious for any language. I may add it as a best practice. Commenting and Documentation too! Thank you again! Very appreciated!
Take my advice. I don't use it anyway.
-- greengaroo
In reply to Re^2: 20 most important Perl Best Practices
by greengaroo
|
|