Book review: The Design and Evolution of C++

This book is very interesting in that it doesn't tell you how to program in C++ but rather highlights why C++ is the way it is today. It starts with the very roots, an extension to the C language ('C with classes'') Bjarne devised back in 1979, because he faced a software engineering problem at the time where all currently available tools seemed inappropriate. This highly real world oriented design attitude was kept throughout the evolution of C++ - Bjarne specifically didn't want to produce an 'academic' language. This view and the absolute necessity for C compatibility and efficiency explain lots, if not all, of C++s more ugly syntactic and semantic constructs. While the book has chapters dealing with very specific parts of the language, I found the philosophical chapters the most interesting. These explain the author's personal views on programming and design in general and consequently why certain things were accepted or rejected into C++. Bjarne stresses the point that C++ was designed from the beginning to be a 'multiple paradigm' language. Object oriented programming was never meant to be, and is not, the only valid - holy grail - style of programming, that many make it out to be. It's quite frustrating to see features devised ten years ago still not properly supported by the current crop of compilers, templates for example (export anyone?).

The book is not for the novice programmer, but for the experienced C++ user who wants to know the whys behind the language. While a novice might be interested in that information too, it is not an advisable lecture for those readers, since they might easily get confused with the source code examples showing directions in which C++ did not evolve.

To quote one of the design goals: 'C++ is a general-purpose language designed to make programming more enjoyable for the serious programmer' - I think it succeeded.

Book review: The C++ Programming Language

You are a C++ programmer - you own this book. If you don't, buy it, buy it right now. This is the reference work on C++, written by the original creator of the language himself: Bjarne Stroustrup. Although this isn't a book for beginners the text is very readable and concise. I particularly liked the code examples he gives, because they are not of your usual 'hello world' text book quality, but rather examples taken from the real world. He also doesn't commit the crime of many authors of presenting code with remarks like this: "this is not the way you should do it, you'll learn the correct way later". Bjarne isn't the die-hard, everything must be object oriented type of guy (that is a good thing!), thus presenting the more traditional style of procedural programming first. While still taking advantage of the OO facilities of C++, like stream IO for example, he doesn't overwhelm you with the responsibility of designing proper classes from page one. In the more philosophical chapters about design and 'the importance of the individual' the author demonstrates a very rational, non-preaching point of view backed up with lots of real world experience.

No compromises, this book is a must have.

Book review: Extreme Programming Explained

Now this is a controversial book that has caused a lot of heated debate among developers. It starts out innocently enough, by stating the goals of XP which most everyone will agree on: correct, flexible software that adapts well to change in requirements and user-feedback, short development times and happy programmers and customers. It then goes on to explain how the techniques of XP try to help archive these goals. The practices include widely accepted ones, like a rigorous testing process, coding standards and continuous integration. But it also breaks quite radically with common programming wisdom by requiring things like an on-site customer, refactoring as a major component instead of a complete up-front design, pair programming (two developers sharing one keyboard and one screen) and collective code ownership (every one on the team is responsible for the whole codebase and allowed to modify every line of it). It is this mix of proven techniques taken to the extreme and new approaches presented in the book that Beck claims creates a special synergy which leads to a more successful and less strenuous software development process. The author puts forward very convincing arguments for why and how these synergetic effects occur and presents his personal experience using XP on one team as supporting anecdotal evidence. The book is written in an easily readable style and contains lots of sometimes funny anecdotes and quotes. And although it obviously is about the author's pet idea I didn't find it preaching, but rather refreshingly enthusiastic and energetic.

Unfortunately I have to admit that I haven't yet personally experienced all XP techniques in practice, main reasons being that it's very hard to convince management of it's merits ("What?! Two programmers on one keyboard?! No way!") and to get all team members willing to try something new. Maybe if they'd all read this book it would be easier...

In the unlikely event that the ideas don't intrigue you, you still have to buy this book to know what all the hype and controversy is about.

Book review: Effective C++

The subtitle of the book '50 specific ways to improve your programs and designs' is a pretty good summary of what this book is all about. It's is very well structured, the table of contents summarizes each point in one sentence, together with the extensive and complete index it's very easy to use as a quick reference. But thanks to Meyers clear and oftentimes amusing style of writing it's also a joy to read from cover to cover. You'd be a fool if you didn't anyways, since you'd miss out on lots of excellent source code examples and very well stated arguments for each of the tips. Some of the tips may seem obvious, like item 5 which reads: "use the same form in corresponding uses of new and delete". Others like item 1: "prefer const and inline to #define" might seem pretty alien to seasoned C programmers/preprocessor magicians or performance freaks. After reading the author's arguments for his points you'll have a hard time defending your position, though (in the unlikely case that you are still not convinced, that is). Meyers does explicitly encourage critical thinking over blind following of the rules though, and in the tradition of Donald Knuth has promised a reward for every error discovered in his work.

How universally accepted these tips have become you can guess form reading the C++ newsgroups or noticing that they have been fully integrated into automatic source checking tools such as gimpel's PC-Lint. Professional programmers should know these 50 gems by heart - buy the book!

Book review: Design Patterns

This book is a catalog of 23 more or less useful object oriented design patterns in more or less wide spread use. Don't get me wrong, I do like the book's intention of introducing a common vocabulary of solutions to particular engineering problems and it is certainly valuable having these solutions collected and organized in one place. However, I think it is unnecessarily dry and hard to read. The source code examples on the other hand are written in easily understandable C++ with brief mentions of existing implementations or implementation possibilities in different languages. I would have wished for more and more elaborate examples though. The authors often mention the possibility for mixing several patterns to archive their combined strengths, but seldom give code examples demonstrating this - thus leaving the harder problems to the reader. I would have liked less emphasis on the sometimes obscure and outdated 'known uses' section for each pattern - which cites where the pattern has successfully been applied - in exchange for more actual code examples. Sometimes the 'known uses' section reads like an excuse for including that particular pattern, which should be unnecessary, the use should be self evident or the pattern omitted. That said, I still haven't found a use for some of the more esoteric patterns in my everyday designs and application of C++. The book is still a valuable reference, since many patterns (factory, singleton, observer, command) really are in widespread use and you don't want to miss out on their usefulness and seem ignorant in discussions about them ;)

Book review: Code Complete

This is an outstandingly good book about software construction techniques that lead to a sound, robust product. It starts with simple things like naming conventions, function layout and commenting methods, but covers the whole software development cycle of design, programming and quality assurance. Although it gives plenty of source code examples in several different programming languages, these are always short and easy to follow even for 'language foreigners'. Source code examples are only used to illustrate more general, important points, rather than specific implementation details. The author is careful not to force his personal style on you - which would be rather foolish considering the many 'religious' issues covered (naming conventions anyone? ;) ) - but presents his opinions supported by sound arguments that'll make even skeptics reconsider. The text is an easy read compared to more technical books and is covered with lots of very amusing short stories that highlight key points. This book will be a great aid in keeping your and your coworkers' mental health while programming in a team under a merciless deadline.

If you are at all serious about programming - buy this book!

Book review: Accelerated C++

After having read this book I very much regret coming to C++ from a self-taught Pascal and C background - it could have been so much easier. Many introductory texts on C++ assume a background in one of the procedural languages and consequently start teaching the C subset of C++ first. This is, according to the authors' experience, counterproductive to understanding 'proper' C++ and programming true to it's paradigms and design. Thus they follow the radically new approach of discussing whatever (sometimes advanced) facilities C++ offers to solve a particular problem instead of going from one isolated language feature to the next. This leads to the somewhat unorthodox chapter sequence, which teaches the design of user types (classes) after introducing template functions (a feature many seasoned C++ programmers still don't know how to use effectively) or even stranger: the explanation of pointers and arrays (chapter 10) in terms of the standard library iterators and containers, which have been introduced as early as chapter 3. What I particularly liked are the useful and real world examples, although the book does cover the omni-present 'hello world' program, it otherwise fully delivers on it's promise of teaching 'practical programming by example' (subtitle). Due to this approach and the well constructed exercises at the end of each chapter the book gets the student writing non-trivial, useful programs taking full advantage of advanced C++ library features almost from day one. The authors also lead by example and show proper commenting and programming for flexibility techniques even in the smallest code fragments. This is in refreshing contrast to many an author's crime of showing the 'quick and easy' way first and the 'proper' way later.

If you read The Design and Evolution of C++ you'll soon notice the repeated mentioning of Koenig and Moo as two of the key players in the development of the language. Their in-depth knowledge and experience really shows in this work. Although the book is mainly aimed at beginners, veteran C++ programmers can still profit from it, even if only by loosing some more bad old C habits.

Book review: The Mythical Man Month

A classic book about the development and management of large scale software projects. One of the industries veterans shares his experience and his views gathered mainly during the development process of the IBM OS/360 operating system. Yes, this book is more than 20 years old - which makes it even more interesting (or shall I even say: sad?) to see that many of the observed shortcomings and pitfalls are still the industries greatest problems today. Maybe all management and developers alike should be required to read this book prior to getting a job in the field. Although the book does feature some code examples these are few and far in between, it's main focus lies on the coordination and management aspects of software projects. The somewhat poetical title hints at one of the most stressed points, namely that men are not interchangeable and that twice as many engineers don't cut development times in half. Brooks also offers his opinions on the psychological aspects of systems design, backed up by his experience and occasional statistical evidence. This anniversary edition features a review by the author, where he sums up what points he thinks remain valid in hindsight more than twenty years later. I particularly enjoyed a beautiful chapter titled: 'The joys of the craft' where Brooks tries to explain what fascinates and captures him about programming. If you happen to be stuck on a frustrating stretch of your project - read this chapter and you'll feel better - I did.

Book review: More effective C++

This is the sequel to the excellent 'Effective C++' by the same author. It covers more advanced and less general topics than it's predecessor. While the first book gives you good programming style and techniques and points out how to use the language correctly, this one shows specific patterns and solutions to more narrowly defined problems. Examples of these include: smart pointers, proxy classes, lazy evaluation, double dispatching. The book also covers the new standard C++ features more in-depth and thus has a good treatment on exceptions and the new style of casting. Because the topics are less general than those from the previous book they are at the same time more controversial. Rules like 'make non-leaf classes abstract' are seldom followed in practice, even though Scott gives good reasons why one should. Another currently hot topic might be 'program in the future tense', which is perfectly sound at first glance, but eXtreme programming proponents might disagree and would want to word it a little less strong. The author sometimes drifts off on really esoteric tangents which seem unlikely to be relevant in the real world. Item 27 'requiring or prohibiting heap based objects' is such a chapter: while I can see that it might sometimes be useful to place such restrictions on classes the effort necessary to do so is just not worth it in my opinion. This is a case where a simple comment might be better than an overly complex class construct. Another point on the negative side is that the author has the unfortunate habit of introducing you to the wrong way of doing things first and almost convincing you of it and only then goes on to show the correct way. I dislike this from a learning psychological point of view, i.e. you should remember the correct way, not both or even worse just the wrong way.

Scott's writing is as usual clear, concise and oftentimes spiced with funny remarks. All in all a worthy sequel - buy it.

Book review: Game Architecture and Design

This book is a little unusual in that it claims to cover very technical topics while reading more like a light novel. While it was still interesting, it's of the 'read once and forget' type, i.e. I do not regularly get this book out for reference like most of my other technical books. It's biggest problem is that it tries to cover too much ground in too little space (~700 pages) - there is no way to deal with the whole process of developing a commercial quality game in a single book. As a result the author only briefly touches on many topics which would have been better left out for more in-depth coverage from other books. For example, management, architecture design, design patterns and testing each require a book for themselves, rather than a short and superficial one chapter treatment. What's left is a lot of stating the obvious (breaking news: testing is good!) and a lot of personal opinions. While the chapters on design are quite readable, by their very nature they deal with lots of 'religious' issues, and although the author tries to be careful I sometimes felt offended by his preachy tone. I sometimes got the feeling the author had a somewhat ivory-tower, disconnected from reality view on many of the topics, especially the treatment of 'software factories' sounded utopian. The book also features lots of useless diagrams and code snippets of varying quality, which are, presented in isolation, again useless. The highlights are probably the 'case-studies', small anecdotes, scattered throughout the book. In summary, the book is like the internet: an ocean of information but mostly only knee deep.

Book review: Coder to Developer

The book tries to cover the whole of the software development process from planning, team management, coding best practices and finally creating an installer and releasing the product. With such a broad range of topics each one is only treated very superfluosly and shallow. The author has a very tool centric view on things and as such many chapters are just a market overview of available software for the task at hand. I don't think this is of much use for the reader since that is exactly the kind of information you can gather in half an hour of internet research with google - and even after reading the book you'd still have to do this research anyways in order to gather current prices for the latest gadgets. All software solutions presented in the book are for windows only and Microsoft's tools seem to get extra focus and attention. The intended target audience for the book are independant developers and small software shops. As such the author assumes that you are wearing multiple hats and are filling all kinds of different roles from designer to coder to management. I very much liked this perspective on the software world because for one thing I am one such lone wolf developer and second because there are already tons of software books for the large corporate software developer. Those books typically assume loads of process and management and different departments etc which all don't apply for the single developer. Two important things missing in the book's coverage are two chapters: One for the time before concrete planning actually begins on the question of "what to develop" and determining markets. Another one for the other end of the road on how to market your software, how to price it and how to present and distribute it. If those were included I think the book would truly cover the complete process a lone developer goes through from idea to product.

All in all, the book gave me little new information but a good checklist to work through on a project.