Short review of _Writing Solid Code_ 
Author Message
 Short review of _Writing Solid Code_

_Writing Solid Code_ discusses techniques used in various software
divisions of Microsoft for developing "bug-free" code.  It was written by
Steve Maguire, a programmer who did substantial work on Excel (both
for the Mac and the PC) and Word at Microsoft, and is based on years of
experience rather than on an academic methodology.

The book consists of a large number of "does" and "don'ts", each with
a few pages of discussion, case history, and examples (in C).  It's quite
readable.

The coding standards we promote at our company includes much which is
aimed at eliminating bugs by reducing complexity and increasing
readability.  They match those in this book quite a bit, but I still learned
a few things.  For instance, the book recommends making debug versions
of programs in addition to production versions (which we do), but further
suggests that the debug malloc and free routines fill memory with
a value which is easily recognizable in a dump and which, if used as
an address, will probably cause a bus error.  We do have our own
debug malloc and free routines, but they didn't take this extra
step; they will in the next version thanks to this book.

The individual "does" and "don'ts" are, of course, quite worthwhile
on their own, but the main strength of the book is developing a
general attitude of program design and code which places the responsibility
of producing 0-defect programs on the programmer rather than on the testers,
Along that line the books shows programmers how to write code which will
turn up bugs quickly so they can be fixed (as opposed to masking bugs
or ignoring "impossible" conditions).

Notes: the book was published by Microsoft Press in 1993,
ISBN 1-55615-551-4, list price $24.95.
--


(602) 861-7609



Sun, 17 Mar 1996 03:10:11 GMT  
 Short review of _Writing Solid Code_
I can't remember off the top of my head, but was this the
book that said Microsoft canceled some project because
the code had too many unfindable bugs in it.  A first for
Microsoft, but apparently more common at other software
houses.

I wonder what the project was....hmm.....

Anyway, I though it was a pretty good book also.



Mon, 18 Mar 1996 06:57:31 GMT  
 Short review of _Writing Solid Code_


Quote:
>I can't remember off the top of my head, but was this the
>book that said Microsoft canceled some project because
>the code had too many unfindable bugs in it.  A first for
>Microsoft, but apparently more common at other software
>houses.

What is the first for Microsoft, having a product with
a huge number of bugs in it or cancelling aforementioned
product?  In my experience, Microsoft products are about
as buggy as anyone else's.  They have had some very
non-buggy things (Amiga Basic, which was a pretty good
product) and some very buggy things (Word 3.0 for the
Mac which was one of the buggiest programs ever
release).

Quote:
>Anyway, I though it was a pretty good book also.

So I've heard.  I'll have to track it down.

Alan
----
EFI agrees with me 100% on matters of fact.  The above isn't and they don't.


Alias 'C Frog'. Keeper of the alt.tasteless song and part-time evil genius.



Tue, 19 Mar 1996 12:54:30 GMT  
 Short review of _Writing Solid Code_
Quote:

>What is the first for Microsoft, having a product with
>a huge number of bugs in it or cancelling aforementioned
>product?  In my experience, Microsoft products are about
>as buggy as anyone else's.  They have had some very
>non-buggy things (Amiga Basic, which was a pretty good

                   ^^^^^^^^^^^

Quote:
>product) and some very buggy things (Word 3.0 for the
>Mac which was one of the buggiest programs ever
>release).

You've gotta be kidding.

AmigaBasic is incredibly buggy. It was written (badly) for version
1.0 of AmigaDOS; by release 2.0 it was flaky (Commodore dropped it at
that point), and by 3.0 just plain doesn't work.

--

    "A Real Cat's aim is to get through life peacefully, with as little
interference from human beings as possible.  Very much like real humans, in
fact."  (Terry Pratchett)



Wed, 20 Mar 1996 15:51:25 GMT  
 Short review of _Writing Solid Code_

...

Quote:
>a few things.  For instance, the book recommends making debug versions
>of programs in addition to production versions (which we do), but further
>suggests that the debug malloc and free routines fill memory with
>a value which is easily recognizable in a dump and which, if used as
>an address, will probably cause a bus error.  We do have our own
>debug malloc and free routines, but they didn't take this extra
>step; they will in the next version thanks to this book.

A good idea. A similar technique is used for debugging linked list handling
at work. When a data structure is unlinked from a list, it's link pointers are
deliberately set to a value that will cause a crash. We use 0xDEADBEEF. If a
program crashes with reference to this address, you know what to look for.

Anyone else got any cute little tricks to share?
--

                      phone:  61-3-888-5452



Wed, 20 Mar 1996 14:57:14 GMT  
 Short review of _Writing Solid Code_


: >I can't remember off the top of my head, but was this the
: >book that said Microsoft canceled some project because
: >the code had too many unfindable bugs in it.  A first for
: >Microsoft, but apparently more common at other software
: >houses.

: What is the first for Microsoft, having a product with
: a huge number of bugs in it or cancelling aforementioned
: product?  In my experience, Microsoft products are about

Cancelling the product.

: as buggy as anyone else's.  They have had some very
: non-buggy things (Amiga Basic, which was a pretty good
: product) and some very buggy things (Word 3.0 for the
: Mac which was one of the buggiest programs ever
: release).

Apparently, the Word 3.0 fiasco was one of the things that
prompted making the guidelines discussed in _Writing Solid Code_
company policy.

: >Anyway, I though it was a pretty good book also.

: So I've heard.  I'll have to track it down.

It is good, although I've only skimmed it so far.

--
Joe Foster



Fri, 22 Mar 1996 00:38:58 GMT  
 Short review of _Writing Solid Code_

Quote:

>  [...] When a data structure is unlinked from a list, it's link pointers are
>deliberately set to a value that will cause a crash. We use 0xDEADBEEF. [...]

        Be careful with this cutesy device.  The Algol 68-R compiler used to
initialise its storage to the character string "F00LF00LF00LF00L..." for the
same reason -- as a pointer or as a floating point number it caused a crash,
and as an integer or a character string it was very recognisable in a dump.
Sadly, one day a very senior professor wrote a program that called him a
fool.  He had no sense of humour, and very nearly managed to persuade the
university to forbid the use of Algol on its computers.

--
Andy Walker, Maths Dept., Nott'm Univ., UK.



Mon, 25 Mar 1996 21:30:10 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Writing Solid Code & Code Complete

2. "Writing Solid Code" - compiler warnings

3. flame: _Writing Solid Code_

4. flame: _Writing Solid Code_

5. _Writing Solid Code_

6. Querry: A good solid text on writing Macro Assemblers

7. C/C++ Code Reviews and Automatic Coding Standards and Metrics Tool

8. Solid C Code

9. code/classes for Solid Modelling

10. 12 days of Christmas C code, top secret style of code writing

11. REVIEW: The C and C++ Review prerelease version

12. code review practices

 

 
Powered by phpBB® Forum Software