Testing

ajt on 2006-02-22T21:40:03

I got "The Damian"'s PBP last year. Since the start of this month I've been working over some older modules. I've been doing my best to bring them up to "best practices".

Using a combination of the book, Perl::Critic, Module::Build, Devel::Coverage, I've found several no-ops in the code and some subtle bugs that had gone undetected.

I've added loads of tests and currently the first modules I've been really working on is now upto 98.7%, 87.5%, 73.7%, 100%, 100%, 100% and 93% on the test coverage stats. I've got no severity 5 PBP issues, only two severity 4s that I can't fix without changing the API, and I've reduced the number of severity 1, 2 and 3 issues by over half.

I know that following guidelines isn't a panacea for good code, but it's been an interesting process that does force you to think about your code. Is it really okay to deviate from PBP or the guidelines really better? I've also found some bugs, so it's been well worth it.

Think for yourself

petdance on 2006-02-22T22:24:03

Why wouldn't it be OK? Damian isn't omniscient. He's just one guy.

I love the book, and yet I've submitted a talk proposal for OSCON about amending his guidelines.

Re:Think for yourself

sigzero on 2006-02-23T02:29:51

I am curious to know which ones you feel that strongly about that you would come up with an OSCON presentation about it.

Re:Think for yourself

petdance on 2006-02-23T02:39:55

Well, now, you'll just have to wait until OSCON and/or YAPC to find out! :-)

Re:Think for yourself

davorg on 2006-02-23T13:51:33

Well, now, you'll just have to wait until OSCON and/or YAPC to find out! :-)

Ok. I look forward to hearing it in either Birmingham or Brussels :)

Re:Think for yourself

ajt on 2006-02-23T18:32:38

It's all a dialogue, that's what it's all about. Everyone is entitled to an opinion but when it comes to the cruch we have to agree on somethings or we won't be able to communicate at all. I never said I was sticking slavishly to the PBP guidelines, and I would also like to hear other opinions on the matter.

Re:Think for yourself

sigzero on 2006-02-23T21:06:57

Yes it is. I didn't mean to sound "defensive" or anything. I was just curious for knowledge sake. I will not get to be going to OSCON so I guess I will have to wait it out.

Re:Think for yourself

ajt on 2006-02-24T17:40:37

I won't get to go to OSCON either. No offence taken, your point is the key to what I was saying, "using PBP/Perl::Critic" makes you think.

Re:Think for yourself

ajt on 2006-02-23T08:42:09

You have a point, the book is just one set of guidelines. However I do think when you deviate you should ask yourself, am I doing this for a sensible reason, or is the PBP guideline actually a better way of doing things.

I suppose the point is PBP makes you think, I'm not slavishly following the guidelines but so far it's forced me think and as part of the process I've found two no-ops and a subtle bug in one module.

To PBP or not to PBP...

Damian on 2006-02-22T23:59:56

Is it really okay to deviate from PBP or [are] the guidelines really better?

As you consider these pieces of advice, think about each of them in the context of the type of coding you typically do. Question your current practice in the particular area being discussed, and compare it against the recommended approach. Evaluate the robustness, efficiency, and maintainability of your current coding habits and consider whether a change is justified.

But remember that each of piece of advice is a guideline: a fellow programmer gladly telling you what his programming style is, and where he thinks other styles are unclear or make him jump through mental hoops. Whether or not you agree with all of them doesn’t matter. What matters is that you become aware of the coding issues these guidelines address, think through the arguments made in their favour, assess the benefits and costs of changing your current practices, and then consciously decide whether to adopt the solutions offered here.

Be careful though. It's amazing how many arguments about coding practice are actually just rationalizations: carefully constructed excuses that ultimately boil down to either "It's not my present habit!" or "It's just too much effort to change!" Not changing your current practices can be a valid choice, but not for either of those reasons.

Keep in mind that the goal of any coding style is to reduce your development costs by increasing the maintainability, robustness, and efficiency of your code. Be wary of any argument—either for or against change—that doesn’t directly address at least one of those issues.

Re:To PBP or not to PBP...

ajt on 2006-02-23T08:50:31

So, yes, it's okay to deviate from PBP, as long as you think through that deviation, weigh it against whatever criteria you're using to define good programming practice, and stay on guard against the all-too-human tendency to rationalize bad habits.

It's been a really useful process. I'm self taught and work mostly in a team of one (me), so an external viewpoint is really useful. As I said in my original post, looking at every deviation has forced me to think, and while in most cases I've gone with the PBP, it's not always and for good reason.

Re:To PBP or not to PBP...

sigzero on 2006-02-23T21:08:22

I am in exactly the same boat. I have no programmers around me so I picked up Perl to do some things myself. PBP gives me a guideline to go by and I am always interested in other ways or opinions.

Re:To PBP or not to PBP...

ajt on 2006-02-24T13:58:58

There is nothing wrong with being self taught, but you do need to obtain an external view point now and then to make sure your going the right way.

I've been on a Red Hat and an IBM AIX training courses. On both couses I realised I knew a lot already (the Red Hat more so), which is useful confirmation, and I also picked up a better understanding and for AIX in particular I did pick up some new stuff.

Reading the PBP book and using Perl::Critic is a good way of getting an external perspective, but it's only another view.