Writing Solid Code

  • Thread starter Thread starter 100
  • Start date Start date
1

100

Has anybody read Steve Maguire's book "Writing solid code"?
Do you think that the ideas in this book are not applicable in c# language?
Does anybody find
if(2 == i)
istead of
if(i == 2)
as unnetural and does it lead to more bugs in the code because of it makes
programms hard to read.

And my last question is: "Do you think that using boolean expressions
written in this way, asserts and all other *tricks* mentioned in the book is
bringing c/c++ *idioms* in the c# language?"

B\rgds
100
 
"Writing Solid Code" is a superb book; I read it a few years ago and it's
still in my library. Although it's written with C in mind, not C#, it
describes many principles that would apply to any language or development
environment. Obviously in those cases where a recommendation is a
workaround for a language issue that's very specific to C, you have to adapt
it to C# or whatever you're using; it's just a matter of common sense. In
some cases the adaptation may be to not use it at all.

As for bringing C/C++ idioms into the C# language, *if* you are looking for
some kind of ideological "language purity" you are missing the point, IMO.
If it's an idiom that makes C# code more "solid", then it is appropriate for
C#, whether or not it happens to also be appropriate for C/C++. Again, use
common sense. And as with any author, use what you agree with from the
book, and don't use what you aren't comfortable with. No one, especially
Mr. Maguire, is holding a gun to your head ;-)

By the way, assertions are natively supported in C# -- see the
Debug.Assert() and Trace.Assert() methods. They are not a "trick" or
gimmick and are not language-specific, though some languages have better
built-in support for them than others. Asserts are a great tool for bug
prevention.

--Bob
 
So, do you think just because this book was writen several years ago, when
c# wasn't there this makes the ideas in the book not applicable in c#?
Click to expand...

Note that I've never suggested that *none* of the ideas in the book
aren't applicable to C# - I've just argued against taking them
wholesale, when the reasons for some are no longer applicable.
 
Jon Skeet said:
Note that I've never suggested that *none* of the ideas in the book
aren't applicable to C#
Click to expand...

Oops - double negative there. I've never suggested that none of the
ideas in the book *are* applicable to C#. Sorry about that typo :)
 
Thank you guys.
I see that I wasn't express my intention in a right way.
Actually I wasn't lookin for any help. This was most like a survey.
I wanted to find out if there still people like me that believe reading
theoretical books are as good as reading more practical ones.
I think I've been long enough in the programing (my first program was for an
8-bit computer) and long time ago I found that progamming is not like
writing a poetry.
Unfortuantely, reading the posts in the news groups (I'n not speeking about
this particular one) I've got the impression that I think too much when
writing my programs.

B\rgds
100
 
;))))) Don't worry about typos, Jon. I won't note them. In my language
double negatives are legal and they are the only way to to make negatice
sentances. To avoid them, when I speak English, is realy hard to me.

B\rgds
100
 
100 said:
Actually I wasn't lookin for any help. This was most like a survey.
I wanted to find out if there still people like me that believe reading
theoretical books are as good as reading more practical ones.
Click to expand...

But you didn't ask that - you asked whether it was worth using a
specific C idiom in C#.

I have nothing against reading theoretical books - two of my favourites
are "Design Patterns" and "Refactoring" - but that doesn't mean I can't
think it's a bad idea to use an idiom which gets round a specific C/C++
issue in C#, where the issue doesn't apply.
I think I've been long enough in the programing (my first program was for an
8-bit computer)
Click to expand...

The latter bit is true for me as well, and I suspect I'm younger than
most on this group. (I'm certainly younger than most regulars on the
Java newsgroups, or was when we last took a straw poll.)
 
I don't think that the problem is that you 'think too much' when writing
your programs
the problem is with others who are of the belief that their way of thinking
is gospel and that anyone who strays from the true path must be converted
at all cost.
 
I think other replies have indicated that C# is a world away from C++, and
so some of Maguires "how" examples, such as the "if" examples you give below
are no longer relevant.

*However* - I think Maguires original "why" concepts are just as valid as
ever. Generally, he talks about concepts such as:
- Find bugs early, not later (testers find bugs by luck, developers can find
bugs intentionally)
- Let the compiler find bugs for you (the if's etc)
- Developers should know what they mean, and mean what the know (ASSERTs,
contracts, error trapping-not error hiding)

I'm a project lead for a fairly large C# application, and Maguires book is
almost required reading for all developers (we currently only 'highly
encourage' people to read it).

His general concepts are spot on - C# developers just need to find different
"hows" to acheive his "whys".

My 2cents,
Rob.
 
Yes I have read it, several times; and recommend it (along with Code
Complete by Steve McConnell) to anyone that wants to learn to program
well.

But, if you concentrate on what you call 'tricks' instead of the
overall purpose of the book, you are going to miss the point. The
purpose of the book is to get the programmer to approach programming
with the intention of never allowing a bug to enter his code. The
individual 'tricks' are of little importance, if they work well to
prevent you from adding bugs to the code - use them. If they do not
help, follow the theme of the book and find the 'tricks' that do help
you.

C# is a new language, and has new ways of dealing with many of the
problems that existed in previous languages. It is to be expected
that some of what was needed to prevent bugs in a previous language
simple isn't needed in C# as the language itself takes care of it.
But I am certain there are specific things that can be done in C# that
will help prevent bugs that in C/C++ are of no use.

Just watch you code, and when a bug creeps in take the time to look
over how it got in and to figure out a way to prevent a similar bug
from coming in again.

That is after all the focus of the book. Yes it is written for the C
programmer, but that does not change the usefullness of the underlying
theme.

David
 
Back
Top