Hello xlar54,

In general MS's practice and patterns + FXCorp is a good cases to check your
code (with reasonable approach)

BWT, some of us is writing each own articles, for example Jon Skeet's articles
(http://www.yoda.arachsys.com/csharp/) or Peter's http://www.eggheadcafe.com/articlelist.aspx.
There are some guys who run their faqs, for example Bob www.bobpowell.net/gdiplus_faq.htm

Besides this, I run my .NET tips and trics there http://spaces.msn.com/laflour/blog/cns!7575E2FFC19135B4!279.entry

It general
x> I've been going through the newsgroup, picking up best practices and
x> things not to do, as I think it helps to make a good programmer a
x> very good one.  But rather than fishing, I figure that there are many
x> out there who are tired of fixing someone else's poorly written code
x> as it relates to best practices, architecture, security and such.  So
x> to the group, if you had to post a list of "never ever do this..." or
x> "always do this..." what would that include?  We all know there's
x> many ways to do something, but some ways are clearly not good
x> solutions.  My expectations here is that I will learn quite a bit as
x> will everyone else.  Thanks for your replies.
x>
---
WBR,
Michael  Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

No need for further marmalade, here it is:

http://www.tiobe.com/standards/gemrcsharpcs.pdf

Adrian.

Hello xlar54,

BTW, see the http://www.idesign.net site (MS Architects and other notable
guys run it) where in the Resource section is some guidelines

x> I've been going through the newsgroup, picking up best practices and
x> things not to do, as I think it helps to make a good programmer a
x> very good one.  But rather than fishing, I figure that there are many
x> out there who are tired of fixing someone else's poorly written code
x> as it relates to best practices, architecture, security and such.  So
x> to the group, if you had to post a list of "never ever do this..." or
x> "always do this..." what would that include?  We all know there's
x> many ways to do something, but some ways are clearly not good
x> solutions.  My expectations here is that I will learn quite a bit as
x> will everyone else.  Thanks for your replies.
x>
---
WBR,
Michael  Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

Francesco Balena wrote a book called "Practical Guidelines
and Best Practices"; it's for both VB and C#. He has some
of it available for download on his website:

http://www.dotnet2themax.com/

I read this book from cover to cover; it has a lot of handy
tips, and information about "this way runs faster than that".

Robin S.

There are obviously thousands of things that can be done wrong but some of
the most common and avoidable things I see are the simplest things done
wrong, such as:

    if (someBooleanCondition)
    {
         myBool = true;
    }
    else
    {
         myBool = false
    }

instead of:

    myBool = someBooleanCondition;

related to the above, is #2:

    bool myBool = SomeBoolMethod();
    // apply #1 so no if/else
    return myBool;

instead of:
    return SomeBoolMethod();

or, #3,

    myInt = myInt + 1;

instead of:

    myInt++;

or even better:

    doSomethingWith(myInt++);

These are very fundamental coding style issues but applying them makes code
much more readable.

Dale

As to a pair of 'never ever do this...'/'always do this...' lists, I would
take the advice of James Bond (paraphrased) and 'never say never'.

As to a pair of 'these are good techniques...'/'these are not good
techniques...' lists, they would be endless.

But, who is to say what is or is not a good technique in any given
circumstances?

Dale, in this thread, has said that that

 if (someBooleanCondition)
 {
   myBool = true;
 }
 else
 {
   myBool = false;
 }

is bad as compared to:

 myBool = someBooleanCondition;

In general I agree, however, both have their uses.

In a Logic 101 class, the former would be preferred to illustrate a point of
logic, wheras in a C# 101 class, the latter would be preferred to illustrate
a nuance of the language.

Likewise, while:

   doSomethingWith(myInt++);

is perfectly valid from the development coders point of view, from the
maintenance coders point of view it becomes less valid because he/she would
need to go off to the implementation of doSomethingWith to make sure that it
is not defined as doSomethingWith(ref int var) and that the content of var
is not being modified within doSomethingWith.

Number one on my list of foolish things to do in any language is "a
priori" micro-optimization. By that I mean spending hours (or even
minutes) tweaking your code to "improve its speed" before you've
determined that it's slow (and what, exactly, is slow) and needs some
help. Even then, the solution is usually at a higher level: in the
design, in the choice of data structures or things like that.

Of course, it's perfectly legitimate to prefer some constructs over
others if experience has taught you that they're more efficient.

As well, there are areas of computing, and types of problems, that
require screaming tight code. Even in these areas, however, it's a
fool's game to optimize every line of code. The approach is the usual
one: create the best design you can, use the most appropriate data
structures you can, then run your program and find the trouble spots,
and optimize those.

So many people post in this newsgroup, asking whether classes or
structs are "more efficient," or stressing over the cost of boxing,
when in fact they haven't started writing their app yet. (The recent
discussion on boxing overhead excepted: the OP already had a working
app in another language and had a specific question.) So many newbies
think that the way to write good code is to torture and twist the
language to "make it fast" while at the same time they create painfully
bad designs that introduce massive overhead that code tweaking can't
begin to address.

The dumbest "optimization" I've ever seen was this (in C)... I quote it
complete with comment:

// Unwind loop to save clock cycles incrementing loop counter
int a[10];
a[0] = 1000;
a[1] = 1000;
...
a[7] = 1000;
a[8] = 1000;
a[9] = 1000;

Not only was this in the initialization phase of the program (so it
would occur exactly once per program run) but the rest of the program
then built a SQL query and headed off to a database to pull in a few
thousand rows of data. This guy shaved a few microseconds off a program
that ran for five minutes.

If you don't already, start using a a revision control system. If nothing
else is mandated, I use Subversion (http://subversion.tigris.org). It's
platform-agnostic and free.

As for don'ts, the site http://www.thedailywtf.com contains loads of
examples.

Ebbe