I think PBP is a great starting point if you don't want to do any thinking. I would hope that you want to do some thinking when designing your own style guide and practices, however.

I think PBP is a great starting point if you don't want to do any thinking.

actually this book made me think. it says clearly that the "rules" are just suggestions but that you should think about them and whether you follow them or not, you should think about why.

The book looks like the most prominent Java books - do this, do that. The main question IMHO is why and not how.

I think PBP is a great starting point if you don't want to do any thinking.

There's so much to chew on in one little sentence. I think the odds are slim that a person would even glance at a book like PBP if they don't want to do any thinking. It's not one of those pocket guides that give you a summarized list without so much as a "how do you do." There is no starting point for a person who doesn't want to do any thinking. Well, there is: not thinking. That's also the stopping point.

Of course PBP is not the final word. It does give a lot of guidelines along with a lengthy explanation of why Damian likes each one. I don't follow all of those guidelines. Heck, I don't even think I follow half of them. I chose not to take it as a list of commandments, though. It's just a collection of what Damian likes best.

The book did make me think a lot about why I follow the practices I do and how I could improve on them, though. It seems to me that the book was a good starting point for somebody who wants to do a lot of thinking.

That reminds me. Is there any hope for a second edition of "Effective Perl Programming"? That was a pretty handy book.

My interview with Damian Conway for The Perl Review speaks to a lot of these concerns. One of my favorite answers is to my question where I ask him if best practices for an individual can change as they get more experience. You'll have to read the interview to see what he says. :)

Besides that, I think people must skip the preface and introduction. Damian lays out the mindset he thinks developers should be in to use his best practices and make sense of their coding.

I like Perl::Critic, but once in a while I run across a policy that's completely wrong. My personal example today is the one to prohibit conditionals in declarations. That's right for lexicals, because of the unwarned and almost always entirely unwanted pseudo-static behavior exhibited through Perl 5.8... but the policy bafflingly warns about the construct for local variables, which do not exhibit this problem at all.

If I could remember the name of the policy, I'd file a bug against it.

I already reported that bug and it was (supposedly) fixed in 1.079_001.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

It's Perl::Critic::Policy::Variables::ProhibitConditionalDeclarations. I remember because I requested it. I've never heard of this exception for local though. What's the story?

I have testing code (Parrot::Test, for example) that sometimes needs to mark a test as TODO, but for various reasons can't set the appropriate package variable. In the case of Parrot, this is because the code being tested is not Perl. Thus the library contains a line something like:

local ${ $package . '::TODO' } = $opts{todo} if $opts{todo};

This construct is very different than the conditional declaration of a lexical variable because local only controls the visibility of a symbol's binding. The unbinding always occurs at the end of the scope if the conditional is true. Unlike lexical bindings, the false condition does not interfere with unbinding.

xdg is right, and it does appear fixed. Nice!

Having a standard is an effective form of communication when you are dealing a diverse (time or space) membership working in the same problem space. It's saves time, saves effort, and improves communication.

Think traffic laws - they are a set of standards that allow you to know what the driver next to you should do. If those standards weren't there it would difficult to drive, you would have to graft on other forms of communication like hand signals, or curse words to drive safely. What makes them work (when people follow them) is they are reasonable (at least most are), there are not a lot of objections to them, and they are codified and easily obtainable.

PBP is a reasonable set of rules, the community as a whole doesn't have a lot of objections, and it's codified in a nice package, so employing it as a standard makes a lot of sense. It saves time, improves communication, and prevents drunk coding accidents.

That being said, PBP is not the be all end all nor should it be followed blindly, but as set coding standards it has a lot going for it. If PBP (or a subset of it) stops making sense in your organization then don't use it.

That said, I'd much rather a slavish adherence to PBP over a slavish adherence to no best practices (which I see from time to time).

I'm aware of but not very familiar with PBP. I'm also aware of some rather bizarre corporate programming rules, including forbidding indentation, requiring subroutines to fit on a single page of printout (about 60 lines), and even one requiring code to fit on one VDT screen (80 columns by 25 lines).

One thing I would worry about is whether the "do whatever PBP says" are substituting the dicta of PBP for the intellectual judgment needed for code clarity and maintainability, which is, after all, the goal of coding standards. I doubt Dr Conway expects his book to be carved in stone, and its rules enforced by inquisitors (those not currently working at Guantanamo).

The linux kernel coding standards says (amongst other good advice, some of which applies as well to Perl as C:

Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

I think it's generally right, if you go on to read the next two paragraphs:

The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's OK to have a longer function.

However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it than you would have done).

This is very good advice, and I should probably take a closer look at the linux kernel coding standards even though I'm not particularly interested in C or kernel internals at the moment.

Thanks for posting that.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

It are only those of small faith who must seek comfort in the rulings of others.

I think we can all agree that PBP is a set of guidelines, not laws. But the guidelines are very good. If I was starting a new perl shop up, I'd hand that out as the guidelines to use. Like some other folks, I think it's far more common to have complete chaos and disorder than to have fanatical rule following.

Given the two environments, I'd rather have the fanatics. But if I had the choice of working with people who thought about the rules and made conscience decisions to break them where appropriate (and Document those decisions), I'd rather have that.

As it stands today, I try very hard to pass perlcritic -brutal if I can. I use strictures 99% of the time. But I don't get hung up if brutal is complaining about something I don't care about.

Almost any set of coding standards is better than none, and were I working for a boss that was a "Best Practices" fanatic, I would be overjoyed at having such an enlightened employer.

That said, despite that fact that I like the book "Perl Best Practices" quite a bit (I've read it around three times now), once I've added up my questions and disagreements on each point, I personally would only recommend following around two-thirds of Damien's recommendations.

Off the top of my head, a few disagreements:

• He recommends his own Class::Std for doing inside-out objects, but it has problems with threads. Quinn Weaver of SF-perlmongers has been pushing Object::InsideOut, and I would probably try that first.
• He seems to like source filters, and I definitely don't (I don't think that any one who uses the perl debugger would enjoy putting up with source filters). So every time he recommends a module, I need to check to see how it was implemented.
• I like interspersed pod style (where each method has an "=item" accompanying the "sub" that explains how to use the method) -- it has it's problems, but overall I think it reduces the comments you need to write for a sub by supplying some verbal info in the form of documentation. I think his arguments for segregated pod boil down to personal taste (when he looks in a code file he wants to see code).
• I have a number of differences on small stylistic issues, though the only one that comes to mind is that I think "unless" improves readability enough that you should use it instead of "if not", even though it's true that "if not" can sometimes make later edits eaisier.

A few years ago, however, I had encouraged a coworker to learn Perl as a good general purpose scripting language. He bought the book during the endeavour, so I finally got my first look at it. I realised that probably something like 75% of the rules were things that I had independently discovered and already been doing, and the other 25% were mostly logical conclusions of the ones I already knew.

My point is, many competent programmers will probably arrive at many of Damien's ``Best Practices''. I personally spent years to get to that point, and would have spent yet more troubling years to arrive at the last 25%. If I had read Conway's book from that start, it would have served as a good bootstrapping process and would have certainly saved me a lot of time and trouble, as it already has.

Like most of you, I use the book as a reference and as sound advice. I don't agree with everything he's written, but most of his rules do have gems embedded in them, even if you don't agree with them.

As system administrator i'm in the confortable postion to use perl for my own, will say i have'nt regards for other programmers which have to understand my codings. Nevertheless it's in my own interest to write code which is qw/consise structured clear modular re-usable/ and neat.

What i loves about perl mostly is it's undogmatic style. With perl i can "call a spade a spade" . I can write quickest and dirtiest one-liners and due to bash's history they can be used again and again.

On the other hand i can build up big applications which use selfwritten or readymade modules. For better uptaking (?, ger: Begreifen) i like(d) to use "instruments" perl "has on bord" as far as usable. In young history i often prefer CPAN-modules, they are better than mine anyway and my laziness has grown.

I read PBP partially and found it though a little bit dogmatic mainly interesting, especially the chapter "regular expressions". But when i came to the discourse about "inside-out" objects my interest faded because it acted as too "academically" to me. (Presumably i'm only to dumb for that.)

Nevertheless my private o'reilly-zoo has meanwhile twelve exemplars. The book which brought the most benefit to me is, after the "Camel-Book", "Advanced Perl Programming" from Sriram Srinivasan.

regards, Thomas

Damian Conway is a brilliant guy, and he's hilarious to listen to. I can remember one visit to Toronto a few years back that was scheduled for something like two hours, and we ran over by .. two hours?

The funny thing was, I could have sat there for another two hours and listened. It's just fantastic stuff.

However .. I have read PBP as well, and while I agreed with a lot of what was in the book, I don't take it as gospel (reference intended) -- I agree with 90% of it, and usually I follow those recommendations. But I find it too intellectually jarring to conform exactly to what PBP says.

It's almost like the dangerous discussion topic of top-posting and bottom-posting. Most of the time I bottom-post, but sometimes when a quick reply is request, I'll top-post. Or if I'm feeling keen, I'll do a really clean job of bottom-posting by re-formatting all of the previous layers.

I don't use Perl::Critic -- my code is well-documented, and in some cases has really good test cases, but I'm the only one in my organization doing this kind of work (web application programming, socket programming, database programming) and I'm quite busy. The code works, it's clean, I'm around to support it. Enough.

That being said, I like to aim for the following in my code:

1) Functionality
2) Readability
3) Consistency

And I look for them in that order. I suppose when I have a boss who disagrees with my methods, I may have to rethink them, but so far neither employer nor co worker has yet to take issue with the way I do things.

I have to admit to not having sat down and read PBP yet (I've skimmed it), but that's largely because I was fortunate enough to have good CS profs who taught me to start by writing out step by step, in plain English, what I wanted to do and how I want to do it. It's amazing how big projects suddenly become a series of smaller, simple ones that way.

There's no need to set up a server to use SVN. It will run perfectly well against a local repository on the same machine, or over ssh (again without a dedicated server) to a remote machine. And there's other options besides (or on top of :) SVN that don't require dedicated servers either.

Additionally: Not that you're not free to work without a net if you really want to, just don't be surprised when you go splat. And you will eventually go splat (Murphy and what not . . .). And the more cautious who do use SCM religiously will snicker when you're hoist on your own petard.

The cake is a lie.
The cake is a lie.
The cake is a lie.

not applicable to the situation, such as it's insistence on using version control

It is interesting indeed to read others opinions. I started using a basic unix version control system (SCCS) more than 10 years ago, and have used RCS and CVS as well, every day of my life since. I find it to be such a crucial code development tool since it removes all fear from the process:
• the fear of going down the wrong path,
• the fear of commitment,
• the fear of releasing bad code which is used by others

If I make a grave mistake, or even if I just hate what I churned out, retrieving the latest stable version takes mere seconds.

In a way, I was a little surprised version control was even mentioned in the book, if only because I took it for granted that everyone used it as a matter of course. I learn something new everyday.

And what I see instead is that many developers take those exactly as commandments, even if they go completely against the current codebase and guidelines. Just makes no sense.

It's probably their personality. Inflexible, need strict hierarchies where everyone's place is known, basically "fascist" or "autistic" or "would probably prefer Python".

I have been in interviews where if my answer to a question deviated slightly from something in PBP, my answer was deemed completely wrong. Why was it wrong? Because PBP said it was (according to the interviewer)! When I pointed out TIMTOWTDI, the interviewer looked lost. In other words, it seemed that their Perl knowledge was strictly limited to PBP.

Now replace "PBP" with the "Holy Bible" in the previous paragraph and you will get my drift. One thing I have learned in interviews is to keep things simple if you suspect you know more than the interviewer. Otherwise, some people will dismiss you as a blasphemous heathen who doesn't know Conway's God's Laws.

I frequently come across some module or program that spends dozens of lines needlessly predeclaring variables.

Got an example? By what criteria is it needless? Code evolves sometimes, sometimes defaults change, what you end up is with a lot of predeclaring, none of it is needless.