The problem with writing books on programming for novices is getting the pace right as well as keeping your reader out of trouble. The authors of this book chose to introduce C very slowly with the result that much of their code is pretty unimaginative. There is a class of reader for whom this is an appropriate approach. While I would no have chosen to delay the use of string variables (arrays of char) until the last fifth of the book I can understand the motivation.
Equally I can understand the authors' avoiding the need for return values for as long as possible even though one result is that they use the incorrect version of main() which returns void. Actually this leaves them having to touch on a rather more subtle aspect of the language, that of using void as a return value.
I am rather less happy with the decision to delay the concept of a function until chapter 7 (out of 10) but this is a decision within the domain of the author.
What I find completely unacceptable, given the type of reader this book must be aimed at, is code that lies in wait to produce bizarre behaviour. Even worse, code that will almost inevitably result in severe undefined behaviour. Remember that the default type for a floating point number in C is
double. The authors use
floatthroughout. That is rarely going to matter so let us skip it. However they use
%ito read in
intvalues. Experienced C programmers will know that this makes the form of the input significant. There is no reason why a novice should face bafflement because there program gets wrong answers when they type in 012 which they see as twelve and the program converts to 10 (sees it as an octal number). I am not saying that novices should have this explained to them. They simply should never be faced with the possibility of a problem. The
%dformat specifier avoids the issue.
More seriously when the authors eventually get round to string input they give a completely inadequate explanation of the dangers of reading more characters than the available buffer will hold. Indeed most readers will assume that the buffer size is the count of the characters and write over the end routinely. This error is serious. I once redefined a graphics board writing over the end of an array on the stack. I know someone who had had the grave misfortune to reformat a hard drive that way (they had over-written the return from function address which unfortunately then returned into DOS at the point where the disk format routine was located. This book is BORING. It is about the level of 'Peter&Jane' reading books which is fine if it is aimed at sub-teens but most people learning to program want to do a bit more than this book will allow. Even allowing for the authors' claim the book is aimed at novice students (by which I assume they are referring to University students) they should not be insulting their reader's intelligence to this degree. A bright twelve-year-old would pretty soon reckon there was more to elementary programming than this book provides.
That two of the authors are academics goes without saying (you know my opinion of academics writing books for novices) that the third claims to be a programmer of many years experience just leaves me gobsmacked. At least he should have spotted the disasters waiting to happen at run time. On second thoughts perhaps that is rating programming experience too highly as the back cover says he is working in Multimedia and Electronic Publishing.