|Problems? Is your data what you think it is?|
Seeking Best Practices - does your company follow a standard?by meraxes (Friar)
|on May 05, 2010 at 03:51 UTC||Need Help??|
The situation: I am being clubbed to death by PEP 8. Specifically, at my job, there are some well meaning but increasingly vocal folk who wish to abandon Perl for Python. The voices are being heard. I don't have any huge issue with Python... but I do prefer Perl and the idea of maintaining similar code in two languages seems wasteful especially when we already have a bunch of Perl hackers.
I am tired of being beaten about the head with PEP 8 and Python and "how clean" it is and "how easy to maintain" it is. I don't buy it myself. Sure, the code standard is set and the batteries are the same for each install of Python... but people still write bad, undocumented code. I've seen it. We need to show that there's just as good a business case for Perl as there is for Python.
Enter a co-worker. Tired of this, he spearheaded (and is driving) a movement to put together a coding standard for our company with the Perl. Google has'em... can't be all... evil. We have a place to start of course: Perl Best Practices. We're going through it, item by item, to see if it makes sense for us to use at our company. We are now a group of three (possibly four... not sure) doing this. We need to put together something we can sell to management. We, like many, have old code. Hopefully this means we can put together something useful. Create our own standards guide for our Perl code. If we can set a standard and people follow it (by enforcing it... thank you perltidy and Perl::Critic) it'd be nice to stop having PEP 8 thrown in my face all the time.
Business case aside, I agree it's needed. We have many Perl dev's of different levels. Some folk are coming to Perl for the first time... after being taught Python in our local Uni. I'm not looking to "convert" them... but it'd be nice if we could give them a better guide to start them off with than just staring at some bad Perl. In the end, I agree that getting everyone to conform to a standard (even one that not everyone will like... cause they won't) would help a lot of things.
Some of PBP looks a little long in the tooth or hasn't really been picked up by the community. Where do we go from here?
This is where I'm hoping some other monks come in. I've seen a page on the Perl5 wiki that talks about some potential problems/disagreements concerning the modules chosen in PBP. I also recognize that it's not universal (hey, this is Perl after all: TMTOWTDI). However, the "but sometimes consistency is not a bad thing either" part is something we want to get to.
This brings many questions.
Don't get me wrong. TheDamian did a fantastic and wonderful thing with PBP that really brought this stuff to the forefront of the community as far as I can tell from my lurkiness in the hidden shadows. PBP made people talk and think which I think is good. However, I know it's a place to start, not the place to stop... or at least that's how it seems to me.
I appreciate that many of the PBP topics are touched on elsewhere but is this a discussion anyone is having these days? Any feedback, suggestions, discussion would be most welcome. I really just wanted some kind of barometer and an idea of what others are doing and what they think is a good idea. Hopefully I can incorporate this into the building of our standard.