There's some strongly negative reviews for 'Code Craft: The Practice of Writing Excellent Code' but I am not one of those people that feel this is a waste of time reading. Becoming a better developer and designer doesn't come from just one book, one idea, one THING, rather it comes from other things in life by doing/experiencing lots of things and this book is worth the time to read. With 550+ pages of content you will learn about documentation, tools, testing, architecture, source control, etc. You will learn more about what makes a good application and how to go about writing it. You will enhance your development skills and hopefully be better off when you are done with this book.

I like the content of this book and it's tailored towards anyone in the software business that wants to learn to write and design better. While a lot of the concepts in here you will find in many other books, this is a welcome addition to the bookshelf.

My only glaring negative is the boring design in this book. Nothing about the layout makes one get excited about reading it and that's never a good thing. Serious time should have been spent making the inside of the book look better to make the experience better. This isn't a reference book and it doesn't need to look like one.

**** RECOMMENDED

This one is a very good book. It is essentially a book in natural philosophy, not quite "scientific", coming from observation to show you a little bit of everything. An insight to the entire world of programming if you like.

It goes from bottom up, from coding style through techniques and tools to paradigms and architecture. A lot (A LOT) of things explained, briefly, but perfectly understandable. It lacks any analysis or in-depth discussion, but that is on purpose.

Not that many things for an experienced programmer to learn from this book though. To a point where it is boring. It took me longer to read this book through than many others, because I knew much of it in the first place.

The language of the book, the author really is in for wordplay and puns of all sorts, it's all over the place. And although I do believe that proficiency (and desire to excel) in written language is a sure indication of a great programmer, this is not always to the book's best. It sure doesn't read like a textbook, but that's ok. There were a few really good jokes, but most of it is just wordplay for its own sake. For example,

[quote]
This is the really nasty one - when your program isn't pushing up the daisies, just pining for the fjords.
[/quote]

Look, I know what "pushing up the daisies" mean, and I can deduce the meaning for "pining for the fjords" from the context, but having it written like that doesn't really help.

Like some other reviewer, I also didn't like the "good programmers" vs. "bad programmers" checklists. See, being a good programmer (aren't we all ?), I wouldn't know how bad programmers think, thus any attempt to declare "bad programmers do that" would be at best a guess.

What's really good about this book, is that it goes under a positive "do as I do" key, not a negative "don't do as I say", seen much more frequently. I'd guess that the guy is really keen on what he's doing, and you can feel it in his book.

I was pleased to see that yet another author's word supports my belief in that programming is simply patience, discipline and common sense. Oh, and PRACTICE.

Anyhow, a great book for a beginning pragmatic programmer.

I have two comments.
First, do not expect technical details on this book. There isn't. Second, the only paragraph that is really good is on page 461 and it says: "Find the classic books of the field". This is not one of those. He recommends and I agree almost completely:
* Code Complete
* Design Patterns: Elements of reusable object-oriented software
* The mythical man-month
* The psychology of computer programming
* The practice of programming
* Peopleware
* The pragmatic programmer
* refactoring

I do not thing that "Code Craft" is one of those.

I was at the library and this happened to be next to another book that I wanted, so I picked it up too.

And wow, it's rare that I am this disappointed in a book. The content is very thin. It sounds like it was completely gathered from secondary sources, e.g. reading other books about software engineering. It doesn't sound like the result of actual experience.

Every page is filled with platitudes without any examples of real experience backing it up. I'll grant that he has assembled an extraordinarly wide range of *terms* and terminology. It looks like he has tried to shove 3 sentences about every topic in software into a single book. Unfortunately, this ultimately makes for a book with little use.

Another sticking point is the writing style. It comes off like the author is an annoying guy trying to be funny and trying to be your friend. The first sentence irritated me: "What's in it for me? Programming is your passion. It's sad, but it's true."

Huh? Why is it sad that programming is one's passion??? There are similar head-scratchers elsewhere in the book. He also devotes a section to talking about the various types of "code monkeys". And the last type is "You. In the interest of politeness, we'll say no more about this curious beast. Sadly, some people are beyond help..." What? The reader is beyond help? If I pretend for a minute that he's not insulting me, then I still don't know what he's trying to say. This book is incoherent.

And what's with all the reviews below that read like advertisements? Give me a break. It looks like a lot of the author's friends are spamming Amazon's reviews.

I recommend reading Joel Spolsky's books for real, specific insights on programming and the software development process, earned from experience, written in a much clearer and more entertaining style.

I'm also reading Jon Bentley's "Programming Pearls" now.

I was at the library and this happened to be next to another book that I wanted, so I picked it up too.

And wow, it's rare that I am this disappointed in a book. The content is very thin. It sounds like it was completely gathered from secondary sources, e.g. reading other books about software engineering. It doesn't sound like the result of actual experience.

Every page is filled with platitudes without any examples of real experience backing it up. I'll grant that he has assembled an extraordinarly wide range of *terms* and terminology. It looks like he has tried to shove 3 sentences about every topic in software into a single book. Unfortunately, this ultimately makes for a book with little use.

Another sticking point is the writing style. It comes off like the author is an annoying guy trying to be funny and trying to be your friend. The first sentence irritated me: "What's in it for me? Programming is your passion. It's sad, but it's true."

Huh? Why is it sad that programming is one's passion??? There are similar head-scratchers elsewhere in the book. He also devotes a section to talking about the various types of "code monkeys". And the last type is "You. In the interest of politeness, we'll say no more about this curious beast. Sadly, some people are beyond help..." What? The reader is beyond help? If I pretend for a minute that he's not insulting me, then I still don't know what he's trying to say. This book is incoherent.

And what's with all the reviews below that read like advertisements? Give me a break. It looks like a lot of the author's friends are spamming Amazon's reviews.

I recommend reading Joel Spolsky's books for real, specific insights on programming and the software development process, earned from experience, written in a much clearer and more entertaining style.

I'm also reading Jon Bentley's "Programming Pearls" now.

Code craft is an awesome book for anyone who wants to be a better developer. It touches on a lot of practices, viewpoints, areas of conflict, and focuses on turning you into an individual who can work well in a software development environment while leaving the technology / language-specific details to other books.

The book looks simple and juvenile as you're flipping through it at first, but I think it spends about the right amount of time on things and is right up there with classics such as Code Complete and Rapid Development.

I read it cover to cover in about four days and have loaned it to a coworker to look through.

After reading the good, despite few, amazon reviews of this book i decided to pick it up. I'm a big fan of books that teach one how to become a better programmer. Unfortunately, i wasn't too impressed by this one. The author didn't seem to have anything super insightful or groundbreaking to share with us. He gave a description of what he considers to be good code/coders along with a really brief description of a lot of software related tools, paradigms, and 'types' of programmers.

Unfortunately he doesn't really say anything that hasn't been said. His code examples are notably poor. In Steve McConnels book, "Code Complete" he criticizes programming books for using fibonacci as an example of recursion. He criticizes it because it's not something that software developers find themselves doing often. I have the same complaint with most of the code examples in this book (so maybe it is good there are so few). It felt like my high school java teacher (who had neither a CS degree or programming experience) wrote up the code samples. You'll quickly be annoyed by the simplicity of the mistakes and concepts that he is trying to express.

As you read this book you'll find things you agree and disagree with, and you'll just want to say OK. you won't run to your computer wanting to implement them. You also won't run to your friends telling them you've found a new way to do something. I guess that is my major problem with this book, there's nothing really special about it. I also found myself wondering 'why is this important?' throughout the book quite a bit.

I found another thing in this book to be insulting, the Good Programmers Bad Programmers section after each chapter. If i didn't know the difference between a good programmer and a bad programmer i wouldn't have bought the book. They are all very similar and obvious.

I would definitely recommend the following books over it:
Code Complete
Refactoring
Pragmatic Programmer
while this book does cover some things these books say, not enough to replace any one of them, and reading any of these will provide insights this book cannot.

Plenty of books tell how to write code that works - but there's a special art to writing code easy to understand, and that's where CODE CRAFT: THE PRACTICE OF WRITING EXCELLENT CODE comes in. Developers and would-be professionals receive specific tips on how to develop presentation styles, how to handle security issues, and more. From working with teams to developing superior documentation, CODE CRAFT offers up knowledge gleaned from real-world scenarios and reinforces this knowledge with a Q&A section reviewing key concepts. A 'must' for any who would hone coding skills, and for collections strong in software writing and development.

Diane C. Donovan
California Bookwatch

It is rare these days for me to come across a "how to write great code" book that I actually enjoy as much as this one. The reason for this is simple. I do not believe that there is just one way to write well crafted code. Face it we all have our opinions on how code should be written and we are all correct to some extent. However the author Pete Goodliffe does an excellent job in explaining how he feels how we should all write well written code. You may end up disagreeing with what he has to say but I assure you that the journey will be entertaining and thought provoking as well.

One of the best aspects of this book is the generous use of questions that are supposed to foster discussion with either your peers or someone you may be mentoring. The questions are designed to force the newbies to overcome some of their previous misconceptions and apprehensiveness in the process of developing great code. For example a new software developer may not understand the benefits of code reviews so reviewing this chapter before beginning this process could make the process much easier for everyone involved.

The only aspect of this book that I did not particularly enjoy is the use of derogative labels applied to generalized categories of workers. This really does not help in a team environment and rather I believe would create deeper divisions between those that you work with. Rather team building should be more emphasized in this book as that would make the working environment just that more enjoyable. Just my opinion of course.

It is rare these days for me to come across a "how to write great code" book that I actually enjoy as much as this one. The reason for this is simple. I do not believe that there is just one way to write well crafted code. Face it we all have our opinions on how code should be written and we are all correct to some extent. However the author Pete Goodliffe does an excellent job in explaining how he feels how we should all write well written code. You may end up disagreeing with what he has to say but I assure you that the journey will be entertaining and thought provoking as well.

One of the best aspects of this book is the generous use of questions that are supposed to foster discussion with either your peers or someone you may be mentoring. The questions are designed to force the newbies to overcome some of their previous misconceptions and apprehensiveness in the process of developing great code. For example a new software developer may not understand the benefits of code reviews so reviewing this chapter before beginning this process could make the process much easier for everyone involved.

The only aspect of this book that I did not particularly enjoy is the use of derogative labels applied to generalized categories of workers. This really does not help in a team environment and rather I believe would create deeper divisions between those that you work with. Rather team building should be more emphasized in this book as that would make the working environment just that more enjoyable. Just my opinion of course.

I picked up this book because I chanced upon an excerpt from it online and thought it might be an interesting browse. It turned out to be far more than that, much better than I had even anticipated.

First of all, it is an easy and enjoyable read, which isn't a description you can give to many books that delve quite deeply into technical theories and topics. Not only is it well written in clear prose, his subtle, gentle humour succeeds in turning what could so easily be a long, boring dry list of do's and dont's into an interesting and satisfying book.

The author comes from a C language background and uses this for the examples, but - even though VB is my particular language of choice - I didn't find the use of C to be a problem at all. The examples are generally quite short and the logic or the point being made is always clear to see.

Although a huge amount of research has clearly gone into the writing of this book, it is always apparent that most of the examples are from his own personal experience. Again this adds value and credibility to the points that are being made.

I read this book from cover to cover, (not something I usually do) and have already taken many of his suggestions on board and know that I will go back to it again and again in the future.

A really first class book that delivers on its promise. If you take the time and trouble to read it and assimilate the guidance it will certainly help you to write excellent code.

Almost any programmer can program. That's more or less the definition of the word. It's pretty rare (but not unheard of) to find a C++ programmer who doesn't know C++.

So what's the difference between a good programmer and a bad one? Usually it's all of the thousands of disparate things that a programmer needs to know to be effective that don't deal with the programming language itself. Things such as design principles, coding standards, testing strategies, understanding of tools, and general development philosophy.

Those are the topics of this book. "Code Craft" won't teach you how to build generic collection classes and optimized tree search routines in Visual Basic or any other language. Instead it focuses on the myriad skills a good programmer uses while building an application. Things such as defensive programming, how to format code, using meaningful names, testing, and source code control. It describes different kinds of programmers and project organizations, and explains how to with the strengths and around their weaknesses. It explains how to write specifications, perform code reviews, and estimate project lengths.

Pete Goodliffe is an experienced professional developer and it shows in the book's right-on-the-money tips. His advice and experiences (as shown in frequent interesting sidebars) agree with mine in almost every way. Of the many tips in this book, the only one I found that I don't agree with is the idea that you should write the fewest possible comments, including only those that are absolutely necessary to explain the code.

Even that minor criticism demonstrates why I think you should buy this book: to get different points of view. There are several books available that deal with these sorts of higher-level programming issues including "Code Complete" by Steve McConnell and "Writing Solid Code" by Steve Maguire. They all follow the same general theme but each reflects the personal experiences of the authors.

Pete Goodliffe's writing style is fact-filled, easy to read, and downright entertaining. It's perfect for reading on the bus, during the half hour before a meeting when you don't really have time to start writing a new subroutine, and sitting behind the ficus during those awkward cocktail parties that marketing throws to impress customers.

This is a language-neutral book. It focuses a bit on C++ and similar languages but there's plenty of material to benefit developers using any language. Buy it and read it as you have time. If you pick up even a single new tip, it will be well worth the effort.

Almost any programmer can program. That's more or less the definition of the word. It's pretty rare (but not unheard of) to find a C++ programmer who doesn't know C++.

So what's the difference between a good programmer and a bad one? Usually it's all of the thousands of disparate things that a programmer needs to know to be effective that don't deal with the programming language itself. Things such as design principles, coding standards, testing strategies, understanding of tools, and general development philosophy.

Those are the topics of this book. "Code Craft" won't teach you how to build generic collection classes and optimized tree search routines in Visual Basic or any other language. Instead it focuses on the myriad skills a good programmer uses while building an application. Things such as defensive programming, how to format code, using meaningful names, testing, and source code control. It describes different kinds of programmers and project organizations, and explains how to with the strengths and around their weaknesses. It explains how to write specifications, perform code reviews, and estimate project lengths.

Pete Goodliffe is an experienced professional developer and it shows in the book's right-on-the-money tips. His advice and experiences (as shown in frequent interesting sidebars) agree with mine in almost every way. Of the many tips in this book, the only one I found that I don't agree with is the idea that you should write the fewest possible comments, including only those that are absolutely necessary to explain the code.

Even that minor criticism demonstrates why I think you should buy this book: to get different points of view. There are several books available that deal with these sorts of higher-level programming issues including "Code Complete" by Steve McConnell and "Writing Solid Code" by Steve Maguire. They all follow the same general theme but each reflects the personal experiences of the authors.

Pete Goodliffe's writing style is fact-filled, easy to read, and downright entertaining. It's perfect for reading on the bus, during the half hour before a meeting when you don't really have time to start writing a new subroutine, and sitting behind the ficus during those awkward cocktail parties that marketing throws to impress customers.

This is a language-neutral book. It focuses a bit on C++ and similar languages but there's plenty of material to benefit developers using any language. Buy it and read it as you have time. If you pick up even a single new tip, it will be well worth the effort.

This book's a terrific resource for developers wanting to learn or teach good coding practices. This book is all about how to do software construction the right way. The book will inevitibly suffer from comparisons to McConnell's Code Complete, Second Edition -- that's a very, very tough shadow to try and get out from.

Code Craft seems to me to stand up to that tough comparison. Goodliffe's writing style is easy to read, and the points he makes are critical to folks who give a hoot about writing good software. The book's topics are well thought out, running from defensive coding practices, through the importance of coding standards, solid design, good processes, and a high-level view of methodologies and practices.

The level of detail is generally right on, although on occasion a passing reference is tossed out in a critical context without additional examples. One of these cases would be his blurb to "consider the Cheshire cat/pimpl idiom" without the least discussion of exactly what the heck that is. However, and this is important, in many such cases Goodliffe provides a bibliography citation on such topics, which means you can chase down that reference in some other work. While sometimes annoying, such an approach helps keep the book from being a complete monster -- it weighs in at around 580 pages.

I very much liked the on-topic sidebars scattered throughout the book. They show great examples which tie in with the current topic, such as showing when the right time to use defensive programming is (all the time!), or some quick discussion on how to approach licensing your software. I also like the 10,000 Monkeys comics dotting the work. They're amusing and keep the tone of the book light but still focused.

Code Complete is such a seminal work that Goodliffe's book will probably have a bit of a tough time making the inroads it deserves simply because McConnell's work has such a head start. Still, Code Craft is a solid book and highly useful to all developers, and it deserves a place on the bookshelf. (And you should read it, not just have it on your shelf.)

The title of this book, Code Craft - The Practice of Writing Excellent Code, suggests something more than just the code itself. It is really about the practice of writing better code. Many of these practices are captured in this book and presented as a series of DOs and DON'Ts that summarize chapter content. This makes the book easy to read from any starting location except perhaps at the end of each chapter!

Pete's writing style is a very engaging combination of extremely thoughtful content and an abundance of ability to poke good-natured fun at many of the commonly-seen failed-practices in the software industry. I found myself being echoed by Pete's numerous observations as if we each had had a lifetime of shouting the same messages to deaf ears of an emerging generation of coders. I felt very connected to Goodliffe's presentation throughout the book. I would find fault only in those situations where the content stopped being truly aggressive in its expose-style of offering sound advice. What I mean by this is that throughout the book, Pete offers a wealth of advice, but often stops short in providing useful examples of what he means by "idioms." Because the book tends toward programming language neutrality, I find it fair to state that he probably can not be as expressive in pointing out the idioms for such a wide variety of languages. However, it also seems clear that Pete is most decidedly a "strongly typed" programmer, so I personally would prefer to see more detailed discussion of the idioms he alludes to in several passages. He does elaborate in a couple of areas, so let me state that this is simply a preference of mine as opposed to a true fault in the content. However, as he states in Chapter 3, "just as fluency in a natural language depends on understanding its idioms, fluency in a programming language requires idiomatic usage," I would like to see some compilation or other call-out to some common idioms that would answer the question "such as?" Otherwise, the advice, though sound, tends toward the generalistic rather than the specific, which, in a book aimed at CODE and not LANGUAGE seems appropriate if not a bit of an annoyance.

Throughout the book there are nearly an unlimited supply of "bubbles" with meaningful anecdotes taken from the author's real-world experiences. If I could just share half of these with the population of programmers who are the likely reason for them, I'd be satified that the book accomplished a vital and important mission objective.

The one thing that I'm left with after reading Code Craft is a strong desire to meet Pete Goodliffe in person, if only just for a coffee. He is obviously intelligent, organized and is a true artist in many ways including putting together a book that reads very well and contains a very good grip on the issues surrounding software development in a wide variety of organizations from start-up to expansive brick-n-mortar and even Internet-distributed.

The book touches rather well-focusedly on just about every imaginable aspect of writing code in our current era. No reasonably area of the day-to-day working-life of a programmer is left untouched by this very well-rounded book. Throughout the book, Pete poses a steady-stream of questions that we're to ask of ourselves. This thoughtful interrogation approach is perhaps the only useful way of moving us toward the "light" of more-proper programming traits. He exposes a few of the more common "personality traits" of bad programmers without being a Dr. Phil or Ruth of whatever in an attempt to try to push away bad habits and open the door to making better decisions.

The book is worthy of 4-1/2 stars, so I error on the side of caution, which is what I'd think Pete would choose based on my take of his defensive posture when coding. Something that I really, really liked about the book was the numerous quotations included from nearly all facets of life now and long before computers ever used electricity. The 10,000 monkeys (Dilbertian-style cartoons throughout the book) was initially a bit annoying to me, but soon became a "must-read" when encountered due to their relevance to the some of the many underlying issues related to the content where they were located.

The one litmus-test that I have for a book of this level of rating is: If I can open it up to any random page within the interior content and find something useful, meaningful, relevant to the topic and well-written, then the book passes the test. It is very rare that I can't randomly open a book and get the "novice spiel" rather than something truly meaningful and useful. I challenged this book repeatedly and every page I opened to was worthy of a full 4-1/2 stars. I highly recommend it for all programmers. If you find yourself agreeing with everything that Pete wrote, great! If you find yourself arguing or finding excuses for not doing what Pete wrote, then you really need this book. I strongly recommend this book for all programmers, with perhaps a bit more emphasis to those using a more strongly typed language. If you read the book and find that you already know most of what it contains, then you are probably the best person in the world to recommend it and pass your copy along to someone you know who can REALLY use it!

I'd like to mention one thing about the front cover, which may not be clear from the Amazon image(s). If you've ever assembled a model airplane, car, ship or other form of plastic, prepackaged kit, the cover art is a plastic "model" of elements of coding language in small "model parts" along with a tube of model glue. I believe that the cover is incredibly representative of the intellect that went into producing the content in this book. Kudos to all involved!