|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|How to Solve It|
|Programming Pearls||The True Believer||Lions' Commentary on Unix||K&R Book||Rapid Development||Winner-Take-All Politics||Military Incompetence|
|Alice's Adventures in Wonderland||Tao of programming||AWK book||Animal Farm||The Elements of Programming Style||Humor||Etc|
This book written by Brian W. Kernighan and P. J. Plauger is one of the first studies of programming style. It advocates the notion that computer programs should be written not so much to satisfy the compiler or personal programming "style", but also should strive for general "readability" and "understandability" by humans with the specific goal to make software maintenance easier.
We will discuss the second edition: The Elements of Programming Style Brian W. Kernighan, P. J. Plauger (second edition; January 1, 1978) ISBN-10: 0070342075
The first edition was published in in 1974, four years before the second. This is a very small book, just 168 pages long.
The book's title and tone is a based on famous The Elements of Style, by Strunk & White . It has spawned multiple imitations tailored to individual languages, such as "The Elements of C Programming Style", "The Elements of C# Style", "The Elements of Java(TM) Style", "The Elements of MATLAB Style", etc.
The main content of the book is discussion of "short and wrong" examples from published at the time programming textbooks. This makes the book more interesting and more practical, as abstract preaching soon generates opposite reaction from the one intended.
The style is diplomatic and generally sympathetic in its criticism, — some of the examples with which it finds fault are from the authors' own work (one example in the second edition is from the first edition).
The book now is slightly outdated as Fortran examples are probably pretty foreign to most readers. Also usage "all-caps" program listings reminds of the punch cards era and is definitely a distraction and actually oversight of the authors for the second edition. Still this book was a lasting value as a pioneer, which created the new genre of "follow-up" programming style books both generic and language-specific, for almost any language.
Among language specific:
The book pioneered the field of critical redesign and refactoring of the code snippets. It concentrates of micro-level, not touching more complex architectural and algorithmic issues. An interesting detail that probably contributed to the long life of the book is that examples which they criticize and try to improve were taken from published textbooks and articles.
Authors also try to provide some generic, language independent rules and recommendations for programmers. In this area their success is mixed. Programming style is not a dogma and often textbooks with the word 'style" on the cover provide trivialities or some stupid advice. For example advice to avoid multiple exist loops depends on the language: if the language neatly incorporates such a construct, why not use it ?
Still by-and large the discussion is pretty intelligent and authors try to avoid banalities or overgeneralization. Programming is an art and in no way it fits any set of rigid rules. But 77 rules provided in a book can serve as a useful guideline and starting point for thinking about "What to do and what not to do" in writing complex programs in compiled languages. Some of the recommendation are also applicable to scripting languages.
The book also contains several interesting discussions of how to transform the program to a better one and common pitfalls in programming. The authors have provided an useful set of tips for coding (and sometimes design).
Chapter 5 lists "Common Blunders" such as an un-initialized variables, too lexically close variables names (identifiers preferably should differ by at least two letters to catch typical typing errors), etc. They point out that there is no guarantee the code will match the comments over time.
Their use of Fortran and PL/1 is regrettable (but the book is really old and C was not used much at the time), but still is hardly a problem. Outdated version of Fortran used now is a bigger 0 distraction then PL/1. Still any competent programmer should be able to read the examples easily and understand the key idea of the examples provided.
PL/1 examples are still readable after all those years (all caps listings is just sloppiness of the authors). Actually PL/1 which fall a victim of programming fundamentalism now can be considered to be a small, rather elegant Algol-style language :-). From the PL/1 examples provides it is clear that the designers of C fall into the trap of oversimplification and C contains problematic areas that are absent in PL/1 (exclusion of string handing from the language was probably the main blunder -- weak string handing using the library hunts the language, too primitive preprocessor, which actually is abused/overused; unability to close multiple levels of nesting, absence of subroutines with multiple entry points, etc). PL/1 pioneered many classic functions for dealing with strings such as index, substr and tr (the latter made its way to Unix as a utility).
The book is the source for a well known quote on writing software: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
Here is a summary of the important programming style tips from Brian Kernighan's 1994 guest CS50 lecture:
As one reviewer of the book on Amazon noted:
I dare say many rules Mr. Kernighan preached almost three decades ago are still NOT followed by the programming community at large. For examples, "Modularize. Use subroutines." "Each module should do one thing well." and "Don't patch bad code--rewrite it." A widespread, bad practice of 90% of the programmers today is still writing functions that are way too long! And they very often keep modifying existing functions--inserting new logic into them--to make already bad code even worse; they seldom give it a second thought about rewriting the whole damn crap!
Another set of rules from the book: "Make sure code and comments agree." and "Don't over-comment." Many programmers seldom do the first thing, resulting in widespread mismatches between the actual codes and surrounding comments. This applies to Java code as well. The comment style recommended by Java--that is, mixing code and comments that can be extracted into so-called self documentation--is an outright violation of the "don't over-comment" rule. (This is intended to be a criticism of Java-style comments.) Good code should document itself clearly; with perhaps a little help from judiciously added few comments that are not self-evident from the code itself.
The book uses FORTRAN and PL/I code examples. There are things that no longer apply today. But the fundamental rules and styles are still well applicable today and in the future.
|News||See also||Reviews||Recommended Links||C History||Programming style||Perl Style|
|Programming Pearls||Rapid Development||Tao of programming||The Mythical Man-Month||Lions' Commentary on Unix||Humor||Etc|
Still Offers Good Advice, December 4, 2002
By Paul J. Mantyla (Sunnyvale, CA USA) -
This review is from: Writing Solid Code (Microsoft Programming Series) (Paperback) The negative reviews I've read tend to fall into two categories: 1) Anti-Microsoft Bashing and 2) Nitpicking.
This book isn't a recipe book, and it's a bit dated, having been written during the days of DOS and the first Macintosh, but the underlying themes and general advice are still valid:
- Enable compiler warnings and pay attention to them.
- Use assertions to validate your assumptions.
- Don't quietly ignore error conditions or invalid input.
- For a complicated, critical algorithm, consider using a second algorithm to validate the first. (e.g. validate binary search with a linear search).
- Don't write multi-purpose functions such as realloc (it can grow memory, shrink memory, free memory, or allocate new memory -- it does it all).
- Check boundary conditions carefully.
- Avoid risky language idioms.
- Write code for the "average" programmer. Don't make the "average" programmer reach for a reference manual to understand your code.
- Fix bugs now, not later.
- There are no free features; don't allow needless flexibility (like realloc).
- Ultimately the developer is responsible for finding bugs; he shouldn't write sloppy code and hope that QA will find all his bugs.
J Nagler - PS: Political Science and Politics, 1995 - jstor.org
See also 10 Commandments for C Programming by Henry Spencer
These were written by Henry Spencer a programmer and engineer for the Canadian Space Agency. They are published widely on the web but as that is ephemeral are included here, I understand they are in the public domain but should that prove wrong, please notify me by email at email@example.com. it is About.com's policy to always respect copyright.
My summary of his commandments is
- Use Lint (Less needed today but if you have it...) or Static Analysis
- Care with Null Pointers.
- Cast away Potential Problems
- Publish Library Function Headers
- Check Array Bounds
6-10 are on Page Two
- Always Check Return Error Codes
- Don't reinvent the Wheel
- Write Clearly Not Cleverly
- Make Identifiers Unique in the first 6 Characters
- Avoid Lack of Portability
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style, McGraw-Hill, New York, 1974. ISBN 0-07-034199-0
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style 2nd Edition, McGraw Hill, New York, 1978. ISBN 0-07-034207-5
J. Plauger selected quotes from The Elements of Programming Style
Style Examples and Counterexamples BW Kernighan, PJ Plauger - ACM Computing
Surveys (CSUR), 1974 - portal.acm.org
The Elements of Programming Style - fortune cookie is a fortune cookie file containing the 69 tips from the "Elements of Programming Style" by Kernighan & Plaugher.
Geek Réplique Dennis RitchieDennis Ritchie, renowned author of the C programming language, obligingly responded to our query as follows:
I don't usually answer this kind of request; various Who's Who compilers have gone unrequited. Nevertheless,
I follow my nephew's advice. He advises me that Power Rangers are getting tired..
That which is is just past the earliest of its kind.
They are pretty much all the same.
http://www.cen.uiuc.edu/cgi-bin/ryl (now broken, sorry!)
1985 VW GTI
S. J. Perelman
Dr. Strangelove, or: How I Learned to Stop Worrying and Love the Bomb
Black jeans, shirt with collar
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: October, 20, 2014