Search in Book Reviews

The publisher has done a great job of presentation. The book is a full colour publication on slick paper and at an exceptional price for books on programming. That is where it stops.

The front cover claims 'Plain English', 'Fully Illustrated', 'Easy to Follow'. Well it depends on your concept of what those terms should mean. The author does not appear to have any kind of concept of what is reasonable to expect of a newcomer. He often uses 'programming jargon' (i.e. terms with special meanings in a programming context) without giving any kind of explanation. 'Fully Illustrated' apparently means lots of marginal icons and endless screen shots of source code and output from executing toy programs. 'Easy to Follow' means that the author will tell you lots of things without showing you what they are good for.

The book does not have an introduction so I started to read the first chapter in an attempt to discover who this book is for. There I found a section headed 'Why learn C programming?' Here are the first two paragraphs of that section:

Leaving aside the somewhat weird use of English as manifested by the last sentence of the first paragraph (remember, 'Plain English' and 'Easy to Follow') the thrust of these paragraphs is quite untrue. C is a very difficult language for newcomers to programming because it is relatively terse and assumes familiarity with programming. That is not a fault with C, it was designed by a programmer for programmers and those who were already well familiar with programming concepts. C is sometimes described as a high level portable assembler. By its very nature it needs the programmer to understand something about the underlying hardware. I do not think anyone who has actually successfully taught programming would elect to use C as a starting point. Well I might in a classroom full of students who were well versed in electronics and wanted to write code for small, embedded systems but that is a very specialist group.

The very next section, 'Standard C libraries' starts with the following paragraph:

Note that this is the top of the second page of text. At this stage the reader has little if any idea as to what a function is and why it might be helpful. The reader is going to find it even harder to understand why s/he needs to tell the linker where the libraries are having been told they are header files (which they will later be told to #include into their program - well actually, no, because the author never invites the reader to write a program, just to copy his.)

Chapter One ends with a section on comments (I have passed over several further pages of plain geek speak, i.e. it is English but will not add much to the newcomers understanding unless they are already firmly immersed in the computer culture.). Here the author excels himself with a set of comments that demonstrate exactly what comments should no be. Things like:

/* declare the obligatory main() function
 */

By the way he has no idea about the difference between 'declare' and 'define' which will make it harder for the reader when they come across code that separates out pure declarations (such as the main contents of a header file) from the definitions used to create object or library files.

Chapter two is about storing data. In 16 pages the author goes from 'Creating Variables' through such things as register variables and data conversion before finishing up with multi-dimensional arrays (note that we do not yet know what a function is.) Would you like to guess what he uses for data input? Yes, good old scanf(), just what every newcomer needs in order to reformat their graphics card (seriously, I once managed to do exactly that). Of course we need input, and if we are going to play with numbers we might even use scanf() but the problems a newcomer is likely to face deserve more than half a page of text, followed by a miniscule program and a pretty picture of the screen output from running the program.

These are not easy steps but whopping great leaps where being on the Moon would be a great advantage.

The next chapter is titled 'Setting constant values'. The first page covers the use of const in declarations (and the author comments, 'Notice that it is convention (sic) to use uppercase characters for constant names, to readily distinguish them from variable names in the program code.' thereby ensuring that the poor innocent will get bitten by the pre-processor as often as possible.) On the next page the author covers enums in four brief paragraphs.

The chapter finishes with three pages on the pre-processor (defining constants, conditional definitions and debugging definitions) and the poor reader has not yet learnt about functions.

In fact we have two more whole chapters ('Performing operations' and 'Making statements') to go before we get to functions. Let me skip those. At the top of the second full page of chapter six ('Using functions') we see the following code:

#include stdio.h

void first();     /*declare function prototypes*/

int square5();

int cube5();

Now remember this is C, not C++ so that comment is entirely wrong. Those are not prototypes because prototyping a function with an empty parameter list in C requires the use of void. However this page does lead me to apologise for an earlier insult. The author does know the correct use of 'definition' as applied to a function, it is just sad that he did not use it earlier on.

I think I have gone far enough. A reader who half way through this book can only cope with a simplistic function definition such as:

int square5() {

int square = 5*5;

return square;

}

is not going to cope with chapter seven on bitwise operators.

Frankly I would only recommend this book to someone whom I wanted to persuade to never ever try to program. An experienced programmer wanting to learn C would use something such as K&R, someone with no programming background would be much better off learning about programming using a language which is considerably easier than C.