Re^2: In Need of Mentoring

[chrestomanci]

That book needs to be read with a bucket of salt.

The problem is that it mixes things that are purely individual style, issues that are definite bugs, and everything in between, and does not distinguish between them in the text/

For example, the author of the book favors K&R brace style. Fair enough that is his view, but not mine. I respectfully disagree. Also the author recommends me to write Some::Module::Name->new() not Some::Module::Name::new() because the latter form will cause bugs if Some::Module::Name is a subclass of another module, and does not define a constructor.

The problem is that style issues and real bug avoidance are mixed together without much in the way of distinction and labeling. Each bit of advice comes with a few paragraphs of argument, and if you read those paragraphs you can usually (but not always) deduce which suggestions are just style and which are important, but I would hate for the book to fall into the hands of manager who does not know perl and blindly dictates that the whole book will become the company coding standard.

[mrguy123]

I completely agree with you that blindly dictating the book as coding standard is a mistake. I think there are some great guidelines in the book but also some I disagree with.
This book really improved my coding style and I recommend it for this discussion, but it is of course up to the user to decide which guidelines he/she wants to follow.

I think Larry Wall sums it up pretty well:
We do not all have to write like Faulkner, or program like Dijkstra. I will gladly tell people what my programming style is, and I will even tell them where I think their own style is unclear or makes me jump through mental hoops. But I do this as a fellow programmer, not as the Perl god...stylistic limits should be self-imposed, or at most policed by consensus among your buddies.

[JavaFan]

I would hate for the book to fall into the hands of manager who does not know perl and blindly dictates that the whole book will become the company coding standard.

Never had a manager who thought there was a benefit of enforcing coding styles, but I've met many coworkers who started suggesting coding styles. Most of them, they say "perhaps we should start with PBP". Those people can be easily countered: if you have converted all your OO classes to use Class::Std, come back and we'll continue the discussion". I'm still waiting for the first person to do so.

PBP has some interesting arguments. But nowadays, I only use my copy of PBP to whack people who defend their style with "but PBP says so" over their head. My copy is quite tattered and bloody, as I'm not afraid to use it.