Two Different Languages: Two Similar Books (PBP and CCS)

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:

Perl Best Practices (PBP) by Damian Conway
C++ Coding Standards (CCS) by Andrei Alexandrescu and Herb Sutter

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:

While Conway is a C++ expert (see, for example, his published C++ papers) the converse is not true, Alexandrescu acknowledging he is not a perl pro.
When choosing photo backdrops, Conway is more imaginative than Alexandrescu. :-)

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

Tips on how to go about transforming non-conforming legacy code to adhere to these new coding standards.
Orthogonality and the DRY Principle.
Tips on communication in software teams.
Tips on coding for portability.
Tips on using static and dynamic code analysis tools (e.g. lint, valgrind, Devel::Cover, Devel::Cycle, Perl::Critic, Perl::MinimumVersion, ...).
Summary of guidelines in the form of a tear-off card.

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.

Comment on Two Different Languages: Two Similar Books (PBP and CCS)

Replies are listed 'Best First'.
Re: Two Different Languages: Two Similar Books by pg (Canon) on Oct 16, 2005 at 15:55 UTC
"For Perl and C++ are both mature" Yes, they are both mature, but Perl is also evolving, especially with the active development of Perl 6 (actually even Perl 5). Being mature and evolving are not mutually exclusive, in this sense, Perl shares a path that is more similar to Java's. This evolving gives perl a even brighter future.	[reply]
Re^2: Two Different Languages: Two Similar Books by adrianh (Chancellor) on Oct 16, 2005 at 18:06 UTC
Yes, they are both mature, but Perl is also evolving, especially with the active development of Perl 6 (actually even Perl 5). Being mature and evolving are not mutually exclusive, in this sense, Perl shares a path that is more similar to Java's. To be fair C++ isn't standing still either. See Strousop's The design of C++0x (pdf) for example. It's just a bit harder to spot since perl doesn't have the advantages of multiple implementations and a standards body ;-)	[reply]
Re^2: Two Different Languages: Two Similar Books by EvanCarroll (Chaplain) on Oct 17, 2005 at 02:46 UTC
Technical Report 1, a specification for new functionality being added to C++'s standard library due sometime around year 2008. http://aristeia.com/EC3E/TR1_info_frames.html You speak too soon. Perl6, vs C++/TR1. Now with Hashes! Evan Carroll www.EvanCarroll.com	[reply]
Re: Two Different Languages: Two Similar Books by ioannis (Abbot) on Oct 16, 2005 at 23:58 UTC
From my prospective, it is more important to remember that books on style and practices are meant as general guidelines, they are not laws of nature that always remain true. Writing programs is too complex an endeavor to conveniently fit into methods of right an wrong (tm) : after all; how do you know which of the (possibly conflicting) qualities are important to me, how do you know my (partially contradictory) goals, and how do you know my present constrains? You have no way of knowing. It would be nice to simply follow rules. Does this work, in each an every case? For rules must work in every case; otherwise, I cannot stay confident whether this rule will lead to harm or profit.	[reply]
Re^2: Two Different Languages: Two Similar Books by 5mi11er (Deacon) on Oct 17, 2005 at 15:46 UTC
First off, I, and many others within the Monestary will agree that there are times when (nearly) all the "best practices" will be broken for good reasons. It has even been stated that some of the "best practices" possibly aren't good for some people/groups at all. So, yes, they are best to be looked upon as guidelines, not laws. (And, the title of the book specifically says these are not to be looked upon as laws) Having said that, those who have extensive experience coding in their language of choice are attempting to communicate a set of "best practices" such that those who are not as far along the path as they are, might be able to avoid some of the pain they've experienced along that path. Ignoring them is probably not in your best interest. So, if you are uninitiated, and your point of view is often one expressed by those who've not been on the path very long, you will be better off in the long run if you choose to listen and incorporate as many of the "best practices" as you are able. It will also probably be helpful if you continue to attempt to incorporate these practices as you evolve. As you do this, there will be some practices that you just don't agree with; don't lose any sleep over them, as you said, they are only guidelines. -Scott	[reply]
Re^3: Two Different Languages: Two Similar Books by hsmyers (Canon) on Oct 20, 2005 at 03:07 UTC
One of the things that you learn as an art major is that all rules are meant to be broken when 'needs must'. The hard part is to know just when that is. --hsm "Never try to teach a pig to sing...it wastes your time and it annoys the pig."	[reply]
Re^4: Two Different Languages: Two Similar Books by 5mi11er (Deacon) on Oct 21, 2005 at 16:13 UTC