I don’t find all the suggestions in PBP to be useful, though. Since I’ve just been thinking about them, I thought I’d write them up. Why not go through them all?
At $WORK, I’m currently on a team that’s using all the things in that book which can be handled automatically via the Perl::Critic toolset. That tool has several settings; we’re using one called “brutal”. We are allowed exceptions to that rule, but you have to comment them with a reasonable reason, and the code reviewer can push back on that reason. None of us have been too pushy on that, but it keeps us honest.
On new code, the strictest settings are achievable, and many have benefits. Having the team working all together and having the same expectations has a lot of benefits.
I’m not going to reiterate the practices in detail; they’re in the book. I’m going to post my observations and opinions. That’s all these are; my opinions. I don’t intend to start giant flame wars or heated arguments, nor am I saying anyone who disagrees with me is some kind of idiot. They are no kind of idiot; we merely disagree on a minor technical point.
I’ll begin with the Preface.
The Preface introduces the concept of the book, and encourages you as the reader to think about the suggestions carefully, even if they sound awkward at first. It also discusses how, even if you don’t agree with every one of – or even any of – the suggestions that the examination and consideration makes you a better engineer, and helps you write better code.
I agree with this wholeheartedly and enthusiastically. This may be one of the most missed points in the book. To think and decide what you do, instead of falling into old habits or copy and pasting what you see in front of you. To know why you do something helps you understand what you are doing at every level.
At it’s heart, this is what the book is about, and I think it is a really important thing for Mr. Conway to have said. I found it enlightening when I first read it in 2005, and still find it useful today.
The weakness of the book is that many people don’t do this. They simply say, ‘That’s what is says in PBP!’ and do things mindlessly. They cling to tools and dogma too closely and don’t stop and consider what they’re doing or why. “It said so in The Book!” is not a good reason to do things, at least in my opinion.
There is, of course, nothing Mr. Conway, or Mr. Thalhammer, who wrote Perl::Critic, can do about this. This is human nature; some people want to be told The Right Way and will cling to it no matter what.
Chapter 1: Best Practices
This chapter goes into more detail about why style and consistency matters, and ways to improve style to improve programs as a whole. This was the first place in the book I found myself agreeing with much of what Mr. Conway had to say, but disagreeing with many of his concrete examples.
For example, the book suggests that “appending _ref to the name of every variable that stores a reference makes it harder to accidentally write $array_ref[$n] instead of $array_ref->[$n], because anything except an arrow after _ref will soon come to look wrong.” I agree with the sentiment of what he’s saying there; habit helps you get things right. The example, however, I find weak.
I worked in an time where many C/C++ shops put the variable type in the name, including if it was a pointer, and what kind of pointer. Code like this was common:
char far * lpszDirectoryName = "c:\\foo";
This was useful because you had to be able to tell, editors were primitive, and the compiler was more so. As tools improved, and we could easily hover over something and see what type it was, and as the compiler got better at identifying pointer mismatches automatically, it became burdensome.
It also became wrong, as soon, all pointers were far pointers, and then we simply didn’t care any more, yet our variable names had this soup of unpronounceable cruft at the start. Newer engineers actually didn’t know what they meant.
I don’t think there’s a reason to use _ref, for if you have a reference $array[$n] will fail very quickly, and you’ll fix it. The compiler can tell; you don’t have to burden yourself with looking at it every time you see the variable. I think it’s much more important to know what’s in that array than that it is a reference to an array.
The advice I would offer instead is never to use arrays or hashes. Always use references. Then any reference is always with the -> notation, and you are always prepared to pass them to functions.
So: Good idea, not an example I agreed with.
The section on changing habits being hard is very well thought, and I agree with most of it. Except the examples, but they’re not the point.
I’ll dig into a Practice next. Probably one a day, to keep the posts shorter, as this one’s gotten kind of long.