flame: _Writing Solid Code_ 
Author Message
 flame: _Writing Solid Code_

Responses below:

Quote:

>I've been reading this book, and I must say that it isn't particularly
>useful, except to the dilettante. Most of the good advice is something

You should read his other book.  And keep in mind that he has been leading
teams of developers, new and old for years.

Quote:
>I take great exception to the author's suggestion that a function
>which allocates memory should have an interface like:

> int getmemory(void **ptr, size_t);

I believe he said is that on some machines/architectures NULL might not be
0.  Not likely but possible.  In that case the following would fail...

Quote:
> if (!getmemory(x, sizeof *x)) {
>but he makes no mention of it. I'm led to suspect that he is unaware
>of the requirement that his proposed interface requires the programmer
>to use a temporary ``void *'' object to retrieve the pointer and then

A decent compiler will optimize this away.  And sometimes, manually
expanding code makes it easier to debug and clearer to read.

Quote:
>convert that object's value to the target pointer type in an extra
>step.
>Also, in Chapter 4, ``Step Through Your code'' I was able to immediately
spot
>a bug in an example of incorrect code which the author claims he was only

able

Some of the examples are weak.

Quote:
>I believe that most of the suggestions are simply the authors knee-jerk
>reactions to genuine problems that he has encountered while in the

trenches;

See my first paragraph.

Quote:
>An important element that is missing is analysis; there are no presented
>case studies of a group of programmers using some method versus control
>who do not use that method. Why should I believe that stepping through

I think you'll find this in his other book(s).  They should probably be a
set.

Quote:
>My personal recommendation is that this book is not so bad that it requires
>combustion---it's far better than anything from H. Schildt---but if you
don't
>already have it, don't bother getting it.

I thought it was great.  But then I am more a manager than a coder these
days.

Quote:
>If you want interesting anecdotes, read _The Psychology Of Computer
>Programming_ by Gerald M. Weinberg instead.

Have to pick it up.

Thanks



Tue, 22 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_

Quote:

>useful, except to the dilettante. Most of the good advice is something
>that an experienced programmer would find self-evident.

Not me...  Perhaps I am not as smart?

Quote:
>but he makes no mention of it. I'm led to suspect that he is unaware
>of the requirement that his proposed interface requires the programmer
>to use a temporary ``void *'' object to retrieve the pointer and then
>convert that object's value to the target pointer type in an extra
>step.

I'd much rather get used to writing a little extra code to keep bugs
like these out of my code!

Quote:
>An important element that is missing is analysis; there are no presented
>case studies of a group of programmers using some method versus control
>who do not use that method. Why should I believe that stepping through
>code using a de{*filter*} is more effective than an equal amount of effort spent
>doing something else?

I thought you were "experienced."

Quote:
>My personal recommendation is that this book is not so bad that it requires
>combustion---it's far better than anything from H. Schildt---but if you don't
>already have it, don't bother getting it.

FWIW:  I became a much better programmer because of this book.  But
then I guess each one of get as much as we can out of it?

It's pretty cool that you know C enough that you can see such flaws in
the author's work, but let people like me read it before you burn it!

BTW:  What were you doing reading this book if you already know
everything?

gg



Tue, 22 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_


Quote:

> >I take great exception to the author's suggestion that a function
> >which allocates memory should have an interface like:

> > int getmemory(void **ptr, size_t);

> I believe he said is that on some machines/architectures NULL might not be
> 0.  Not likely but possible.  In that case the following would fail...

This statement indicates an lack of C knowledge. Please read the volumnious
section of the C FAQ on null pointers. Given

        anytype *p = NULL;

Then

        if(p)

will -always- be false, even if the internal representation of a null pointer
is not zero.

Quote:
> >but he makes no mention of it. I'm led to suspect that he is unaware
> >of the requirement that his proposed interface requires the programmer
> >to use a temporary ``void *'' object to retrieve the pointer and then

> A decent compiler will optimize this away.  And sometimes, manually
> expanding code makes it easier to debug and clearer to read.

Eh?

        void *temp;
        char *p;

        getmemory(&temp, amount_i_want);
        p = temp;

A decent compiler will optimize away the presence and use of 'temp'? It
shouldn't.

--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)

Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.



Tue, 22 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_



        [snip]

        [snip]

Quote:

> >I take great exception to the author's suggestion that a
function
> >which allocates memory should have an interface like:

> > int getmemory(void **ptr, size_t);

> I believe he said is that on some machines/architectures NULL
might not be
> 0.  Not likely but possible.  In that case the following would
fail...

> > if (!getmemory(x, sizeof *x)) {

        [snip the rest]

<Jack>

#1  If the function is defined to return an int as above, and
presumably 0 for failure and non-zero for success, the test
above will always work correctly because it is testing that
integer return value, not the pointer.  That was the whole point
of using this function.

#2  If (!pointer) is ALWAYS a valid method for testing for a
null pointer, regardless of the implementations internal
representation of the null pointer.  The ! is an implicit test
for equality to 0, and compile time constants of 0 in a pointer
context are ALWAYS recognized as equivalent to a null pointer.
This is a required feature of the language.  If the
implementation uses a representation for the null pointer that
is not all bits 0, the compiler must "automagically" to test for
the internal representation.

</Jack>



Wed, 23 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_



Quote:
>BTW:  What were you doing reading this book if you already know
>everything?

Joined new company. New boss plopped it on desk.


Wed, 23 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_


Quote:


> >BTW:  What were you doing reading this book if you already know
> >everything?

> Joined new company. New boss plopped it on desk.

Not bad book for new boss to plonk on desk of new guy, I'd say.  Good
boss!

-- Neil.



Thu, 24 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_

Quote:




> > >BTW:  What were you doing reading this book if you already know
> > >everything?

> > Joined new company. New boss plopped it on desk.
> Not bad book for new boss to plonk on desk of new guy, I'd say.  
> Good boss!

Harumph. More like ``Well meaning but misled boss''. Kaz has rightly
taken issue with the book but his mild flame doesn't begin to compare
with my Amazonic BBQ of Maguire's ``efforts'':

Bob Nelson  05/13/97, rating=3:
You'll learn a lot more on Usenet's comp.lang.c newsgroup.  Maguire
doubtlessly had the best of intentions when he authored this book.
However, the book is filled with the Microsoft disease of Hungarian
notation, obfuscating what might otherwise be acceptable examples.
The book is also flawed by DOS-centricity...not surprising,
considering the publisher. Also undermining the value of this work is
Maguire's apparent desire to rewrite the Standard C language (see his
getchar() wrapper). Get the FAQ-list from comp.lang.c. It's better,
it's free and doesn't reek with the stench of Redmond.  

--
========================================================================

             http://www.geocities.com/ResearchTriangle/6375
========================================================================



Thu, 24 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_

Quote:

> Bob Nelson  05/13/97, rating=3:
> The book is also flawed by DOS-centricity...not surprising,
> considering the publisher.

Did you even read the book? Maguire draws mostly from his
experience working on Excel for the MacIntosh.

Quote:
> Also undermining the value of this work is
> Maguire's apparent desire to rewrite the Standard C language (see his
> getchar() wrapper).

He has a valid point: the standard library is one of the worst examples
of library design in the history of programming. It's inconsistent in
every way possible, often has shoot-yourself-in-the-foot defaults
behavior, uses bizarre function names, and has scanf. The only reason
the library exists is because the C standard gave up and codified
it as existing practice.

Quote:
> ... doesn't reek with the stench of Redmond.  

Sounds like you saw the word "Microsoft" on the cover, and made
up your mind without cracking the book.

Scott
--
Look at Softbase Systems' client/server tools, www.softbase.com
Check out the Essential 97 package for Windows 95 www.skwc.com/essent
All my other cool web pages are available from that site too!
My demo tape, artwork, poetry, The Windows 95 Book FAQ, and more.



Thu, 24 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_


Quote:
> He has a valid point: the standard library is one of the worst examples
> of library design in the history of programming. It's inconsistent in
> every way possible, often has shoot-yourself-in-the-foot defaults
> behavior, uses bizarre function names, and has scanf.

Don't forget gets().

--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)

Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.



Thu, 24 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_


Quote:

>> Bob Nelson  05/13/97, rating=3:
>> The book is also flawed by DOS-centricity...not surprising,
>> considering the publisher.

>Did you even read the book? Maguire draws mostly from his
>experience working on Excel for the MacIntosh.

>> Also undermining the value of this work is
>> Maguire's apparent desire to rewrite the Standard C language (see his
>> getchar() wrapper).

>He has a valid point: the standard library is one of the worst examples
>of library design in the history of programming. It's inconsistent in
>every way possible, often has shoot-yourself-in-the-foot defaults
>behavior, uses bizarre function names, and has scanf. The only reason
>the library exists is because the C standard gave up and codified
>it as existing practice.

>> ... doesn't reek with the stench of Redmond.  

>Sounds like you saw the word "Microsoft" on the cover, and made
>up your mind without cracking the book.

Maguire makes a lot of good points.  In fact, I'd say that just about
every point he states is good.  But in too many places his examples
are seriously flawed.

True, the standard library has some terrible examples of library
design.  It's certainly safe to say that the design of gets() was not
the high point of Dennis Ritchies career. :-)

But getchar() isn't terribly designed.  It does have a problem if
sizeof(char) == sizeof(int), but that's extremely uncommon.  Perhaps
Maguire's interface would be better (though, I'm unconvined), but we
live with the history as well as the language and use of getchar() is
so idiomatic in C that a wrapper is more likely to make the program
harder to follow than to help.

Maguire is right when he points out that getchar() can be confusing
for the beginner, but we aren't (or shouldn't be) writing our code for
beginners.  A beginner had better learn to use getchar().  Nothing any
of us does is going to change the fact that, for better or worse, he
is going to have to maintain code containing getchar().

In many ways the book could be excellent, but there are too many
flaws.  I'll add my pet example.

The section "Take Only What You Need"  discusses a function UnsToStr
which converts an unsigned int to a string.  It has some problems:

        1.  Much of the book is devoted to designing appropriate
            function interfaces.  Yet here he presents a function that

            stores using a char* without having the length passed.  
            That is terrible design.

        2.  Elsewhere Maguire, quite correctly, advises against
            writing code that depends on the sizes of basic types.  
            Yet in the second definition we have  ASSERT(u <= 65535)
            [ASSERT is defined elsewhere] and an assumption that the
            result will be at most 5 digits.  Elsewhere Maguire has
            some excellent discussions of making function interfaces
            unsurprising.  A programmer who expects
            UnsToChar(unsigned, char*) to convert any unsigned int to
            a string is in for a {*filter*} surprise.

        3.  If the result is more than 2 digits, the second definition

            uses strcpy() with the source and destination overlapping.

            That results in undefined behavior according to the
            standard.

        4.  There is no mention of the obvious solution -- use
            sprintf().  For efficiency one may need to write one's own

            conversion function, but in the absence of a specific
            requirement one should use standard functions.  Note the
            word "specific."  Making code faster is not a specific
            requirement; making it fast enough is.

--
Michael M Rubenstein



Fri, 25 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_


Quote:
>You'll learn a lot more on Usenet's comp.lang.c newsgroup.  Maguire

Quite honestly, no.  Every time a beginner posts a question, he/she
gets flamed with tons of "go post this question at xxx.xxx.xxx. This
newsgroup is about the C language only."

It's better to go buy a book (specially this one) than to ask an
honest question and be flamed by all the {*filter*}know-it-all people here.

Quote:
>Get the FAQ-list from comp.lang.c. It's better,
>it's free and doesn't reek with the stench of Redmond.  

You're too much of an MS hater, and that undermines the value of your
opinion.  Read a book on debate, you'll learn you make much more of a
convincing argument if you stay away from the words and expressions
that you use in your argument against Microsoft.  Maybe you can focus
on the book, not the publisher, while you rethink it?

gg



Fri, 25 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_


Quote:

> >You'll learn a lot more on Usenet's comp.lang.c newsgroup.  Maguire

> Quite honestly, no.  Every time a beginner posts a question, he/she
> gets flamed with tons of "go post this question at xxx.xxx.xxx. This
> newsgroup is about the C language only."

I have been lurking in this newsgroup for ages now and while I'd consider
myself in a stage further than a newbee I'm far away from the state of some
of the regular posters.

When I first came here, I thought I knew most of what was important about C.
Then I read what was going on for a few weeks - and I learned lots and lots
of stuff I never even considered important and then wondered how I could
have lived  (ok, let's say programmed) without.

I also got the FAQ and read it and while quite a few of the topics covered
there were not new I still found them excellently explained. I was
brilliantly entertained by reading those 'reinforcers' of prior knowledge
and gained invaluable insights by reading the chapters I was unaware of
before.

By observing the customs of the usenet I managed to not get to many flames,
not to embarass myself to prominently and learned a lot of new and important
things about C.

Also, I have not once been sent to another newsgroup - maybe because I asked
there in the first place. Asking there *does* help and I have been told how
to do certain things for the Windows API or how to handle the curses library
under UNIX.

When newbees are told to go to xx.xx.xx to ask, they *will* learn a lot.

Quote:
> It's better to go buy a book (specially this one) than to ask an
> honest question and be flamed by all the {*filter*}know-it-all people here.

I have not read the book Kaz was referring to and cannot compare its
usefulness to this newsgroup but you make it sound as if nothing could be
learned by reading c.l.c to which i have to object. If you ask the right
questions in the right place (preferably asking politely) you will be able
to learn from experts without being flamed.

I will lurk on and learn more by reading what others ask than by barging in
on my own ;-)

Thanks to all the regulars for making the lecture instructive and
entertaining, I do like my daily dose of sarcasm after all.

a (nearly) silent lurker
/urs

--
Urs Beeli - what is grumpiness anyway ?
----------------------------------------------------------------------------
To reply by e-mail remove REMOVE. and .NOSPAM from my mail address



Fri, 25 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_



Quote:

>>You'll learn a lot more on Usenet's comp.lang.c newsgroup.  Maguire

>Quite honestly, no.  Every time a beginner posts a question, he/she
>gets flamed with tons of "go post this question at xxx.xxx.xxx. This
>newsgroup is about the C language only."

Certainly redirections aren't all flames. If somebody, even a beginner,
asks a question that isn't to do with C they will, correctly, be directed
to a more appropriate newsgroup. If they do ask a question about C then it
will be answered here (except possibly where it is answered in the FAQ
where that will be pointed out instead).

Quote:
>It's better to go buy a book (specially this one) than to ask an
>honest question and be flamed by all the {*filter*}know-it-all people here.

There's no substitute for buying a good book, IMO you'll never really
learn C without one. The newsgroup could never be a substitute for that.
What it is is somewhere to turn when you hit something you don't understand,
a bug you can't fathom, fill in the gaps that any C book will have, and
general discussion with other C programmers. What the newsgroup isn't
is a forum for discussing things that are defined by individual platforms
and not by the C language. It is important that C programmers can recognise
the difference as early as possible.

--
-----------------------------------------


-----------------------------------------



Fri, 25 Aug 2000 03:00:00 GMT  
 flame: _Writing Solid Code_



Quote:
>You'll learn a lot more on Usenet's comp.lang.c newsgroup.  Maguire
>doubtlessly had the best of intentions when he authored this book.
>However, the book is filled with the Microsoft disease of Hungarian
>notation, obfuscating what might otherwise be acceptable examples.

Hungarian Notation was the last Cold War coup perpetrated from behind the Iron
Curtain. A vain attempt to bring down our information systems, indeed.

Judging by some of the PC software out there, I'd say the attempt
wasn't all that vain, actually.



Fri, 25 Aug 2000 03:00:00 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. flame: _Writing Solid Code_

2. Writing Solid Code & Code Complete

3. "Writing Solid Code" - compiler warnings

4. _Writing Solid Code_

5. Short review of _Writing Solid Code_

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

7. Solid C Code

8. code/classes for Solid Modelling

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

10. Writing optimized C code

11. standard for writing the code

12. writing portable code for structures

 

 
Powered by phpBB® Forum Software