http://qs1969.pair.com?node_id=500556

My reading of each of the commandment, I found out, follows a rigourous processus. I always punctuate the disclosure of the commandment at hand with an outraged "preposterous!". At around mid-section, it unavoidly morphs into a "hmmm, I can see his point.. but it ain't for me. It just doesn't jive with my vibes". By the time I've made it to the end, though, it is rare indeed that I haven't seen the light, donned the ritual sackcloth and ashes, sworn to atone for my sins and to walk the straight and narrow from now on.

Seriously, I consider PBP to be the best programming investment I did this year. It is worth its weight in depleted uranium bars, and is twice as entertaining. I recommend it heartily to all my friends, whether they be Perl programmers or not. It's that good.

-- `/anick Champoux on PBP

Perl and C++ are very different programming languages. Nonetheless, I use both regularly and recently had the pleasure of reading two similar books about each:

Personally, I was delighted to see these two books appear. For Perl and C++ are both mature, TMTOWTDI languages and now is an opportune time to reflect on the hard won experience of the past 10 years and lay down the law on how best to utilize these complex languages. Doing so clearly and with authority -- as both these books do -- is especially beneficial to programming teams suffering chronic maintenance and teamwork problems at the coal face.

This meditation compares and contrasts these two fine books.

PBP contains 256 guidelines and weighs in at a whopping 542 pages. CCS weighs less: 101 guidelines, 240 pages.

Why is PBP bigger? It covers more ground, with excellent chapters on documentation, testing and debugging -- missing from CCS. Further, PBP is more self contained than CCS, convincingly explaining the rationale behind each guideline in detail, and with fewer external references. Finally, PBP on occasion invents new art, such as unveiling a suite of funky new CPAN modules authored by TheDamian (as if you couldn't guess;-). CCS, on the other hand, deliberately eschews invention. And strives to keep guideline rationales short, often by providing references to external material.

Though longer, PBP is missing a few nice tips from CCS, such as guidelines on concurrency/threading, error-safe code, automated builds and code reviews.

Generally, PBP emphasizes "Robustness, Efficiency, Maintainability", while CCS seems more concerned with "Correctness, Simplicity, Clarity, Safety" along with "uniformity in the right dimension" and "creativity in directions that matter".

Another conspicuous difference is Conway's gutsy attempt to persuade readers on code layout issues, such as space versus tab indentation and braces placement. Personally, I applaud Conway for this (though doubtless others booed). In any case, I found Damian's carefully reasoned arguments convincing. In contrast, CCS's first guideline, Don't sweat the small stuff, timidly exhorts its readers not to attempt to enforce personal taste on code layout.

As for similarities, both books, in addition to language specific recommendations, offer general guidelines applicable to either language; both books, for example, extol the virtues of version control. In addition to specific similar guidelines (detailed below) both books emphasize similar general principles, such as scalability, abstraction, encapsulation, and preferring to find errors at compile time rather than run time.

Conway and Alexandrescu: Separated at Birth

At first glance, Conway and Alexandrescu seem spookily identical:

  • They both come from an academic computer science background.
  • They were both raised in obscure little countries ;-) (Australia/Romania).
  • They have both written two books.
  • Their first books (Object Oriented Perl and Modern C++ Design) astonished their respective communities, receiving rave reviews for innovative mastery of their chosen language.
  • Their second (less exuberant) books, the subject of this meditation, focus on coding standards and guidelines.

On second glance, admittedly, there are some glaring differences:

Some Similar Guidelines Found in Both Books

  • Version control. PBP Chapter 19, "Use a revision control system"; CCS Guideline 3, "Use a version control system".
  • Optimize by benchmarking. PBP Chapter 19, "Don't optimize code -- benchmark it"; CCS Guideline 8, "Don't optimize prematurely".
  • Warnings. PBP Chapter 18, "Always use strict", "Always turn on warnings explicitly"; CCS Guideline 1, "Compile cleanly at high warning levels", Guideline 83, "Use a checked STL implementation".
  • Exceptions. PBP Chapter 13, "Throw exceptions instead of returning special values or setting flags"; CCS Guideline 72, "Prefer to use exceptions to report errors".
  • Variables. PBP Chapter 5, "Variables"; CCS Guideline 18, "Declare variables as locally as possible", Guideline 10, "Minimize global and shared data".
  • Cleverness. PBP Chapter 19, "Don't be clever"; CCS Guideline 6, "Correctness, simplicity and clarity come first" ("Clear is better than cute").

Extra Tips That Might Be Added To PBP From CCS

  • CCS Guideline 2, "Use an automated build system". Less relevant for Perl, admittedly, yet I'm sure, to give just one example, many CPAN authors run all sorts of little automated tools before uploading their module/s.
  • CCS Guideline 4, "Invest in code reviews".
  • CCS Guideline 71, "Design and write error-safe code". This was touched on in Perl Best Practices book: is this one a best practice or a dodgy practice? (though is broader than this little example).
  • CCS Guideline 12, "Know when and how to code for concurrency".
  • CCS Guideline 9, "Don't pessimize prematurely". This guideline argues that, other things being equal, efficient idioms should be preferred to inefficient ones (it's not premature optimization, rather it's avoiding gratuitous pessimization).
  • PBP Appendix B lists just the titles of each of its 256 guidelines; it would be more useful if, like CCS "Summary of Summaries", it further contained a short paragraph summarising each guideline.

Extra Tips That Might Be Added To CCS From PBP

  • Tips on best practices for documentation.
  • Tips on best practices for testing and debugging. To me, the PBP chapters on Documentation and Testing and Debugging are superb. It's a pity CCS hardly touches these important topics.
  • Commenting. For example, PBP Chapter 2, "Code in commented paragraphs".
  • PBP Chapter 2, "Code Layout".
  • PBP Chapter 3, "Naming Conventions".
  • The five PBP Appendices provide a wealth of practical and useful information. CCS has but one appendix, its "Summary of Summaries".

What Might Be Added To Both Books

Books

Other References

Updated 19-oct: A few extra tips plus minor improvements to wording. 23-oct: added more references. 20-jan: added opening `/anick quote.