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
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
Updated 19-oct: A few extra tips plus minor improvements to wording. 23-oct: added more references. 20-jan: added opening `/anick quote.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||