Never Ever...

[xlar54]

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

 

[Michael Nemtsev]

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

 

[> Adrian]

I figure that there are many out

there who are tired of fixing someone else's poorly written code as it
relates to best practices, architecture, security and such.

No need for further marmalade, here it is:

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

Adrian.

 

[Michael Nemtsev]

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

 

[RobinS]

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.


in message
news:[email protected]...

 

[Registered User]

No need for further marmalade, here it is:

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

What does the document naming standard look like <g>?

regards
A.G.

 

[Guest]

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

 

[Michael Nemtsev]

Hello RobinS,

And just adding to your post, about books - the ".NET Gotachas" By Venkat
Subramaniam is really nice book about .NET tips

R> Francesco Balena wrote a book called "Practical Guidelines and Best
R> Practices"; it's for both VB and C#. He has some of it available for
R> download on his website:
R>
R> http://www.dotnet2themax.com/
R>
R> I read this book from cover to cover; it has a lot of handy tips, and
R> information about "this way runs faster than that".
R>
R> Robin S.
R>
R> "xlar54" wrote in message
R> R>---
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

 

[Stephany Young]

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.



in message
news:[email protected]...

 

[xlar54]

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

is bad as compared to:

myBool = someBooleanCondition;

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

I would see this and immediately think - why doesn't the compiler see
this as a perfect opportunity to optimize? Assuming there is no other
activity within the braces, it _appears_ very reasonable for the
compiler to internally optimize this to:

myBool = someBooleanCondition;

Which does raise the point, when we talk about performance and
optimizations, what do we know about the compiler itself and its
ability to optimize code like the above.

 

[Stephany Young]

It may well do.

You could compile both and have a look at the IL, if you are interested.

The next point is a very good one.

The amount of machine resource available tends to make a bit lazy, because
we don't really have to worry about such things these days. It's a far cry
from the days when we had to code, (in COBOL), an ALTERED GOTO instaed of a
PERFORM to save 8 bytes of core memory.


in message

 

[Dave Sexton]

Hi Stephany,

You could compile both and have a look at the IL, if you are interested.

It's not optimized out.

 

[Stephany Young]

It wasn't me that was interested Dave.

I was hinting to the OP that, seeing as he was so interested, that he start
digging around in the IL to find out waht was optimized and what wasn't.


in message

 

[Cor Ligthert [MVP]]

Dave,

As far as I know, there are two optimizing phases. However, I hate those who
set a boolean in a property with only that, you become crazy of that while
debugging.

Just my idea,

Cor





"Dave Sexton" schreef in bericht

 

[Dave Sexton]

Hi Stephany,

I know. I was just validating for the group

 

[Dave Sexton]

Hi Cor,

What two optimizing phases do you mean?

I tested this in the Debug configuration without optimization checked in the properties window for
my VS 2005 project, and in Release mode with optimization checked.

Neither test optimized out the code.

And I agree that code is too verbose for such simple logic.

 

[Cor Ligthert [MVP]]

Dave,

I am one of those who are not really interested in optimizing for
nanoseconds. I am a guy focused on mainenance, therefore I never look for a
nanosecond.

My reply was based on some messages I thought that I had seen from Jay
Harlow, who had tested the casting against the converting: "as" against "()"

Although the code in ILS was different was it (I thought to have understood)
in the real processing the same. That is all I know.

Cor

"Dave Sexton" schreef in bericht

 

[Bruce Wood]

related to the above, is #2:

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

instead of:
return SomeBoolMethod();

....just be aware that some programmers (including yours truly) do the
two-step method because in VS2003 it's the only way you can see what
the result will be in the debugger. I believe that VS2005 allows you to
see function results at the return statement, but VS2003 definitely
doesn't.

 

[Bruce Wood]

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.

Not true in C#. If doSomethingWith is defined as taking a (ref int var)
parameter, then the call would have to look like this:

doSomethingWith(ref myInt)

and could not contain an expression. In C# ref and out parameters must
be specified as ref and out arguments by the caller, so there can be no
surprises. Furthermore, if an argument is ref or out then you must pass
a variable, not an expression.

The case does come up, however, for fields:

doSomethingWith(this.myInt++)

is potentially confusing (but not terribly) if doSomethingWith modifies
/ uses this.myInt internally. It's not terribly confusing because C#
clearly defined the order in which these operations proceed (arguments
must be evaluated before the function is called), so in the end it's
unambiguous.

All of that said, I'm not a fan of cramming as many operations into a
line of code as possible. One of the items on my list of "never, evers"
would have to be constructs like this:

int result;
while ((result = CallSomeFunction(a, b)) > 0)
{
...
}

Blech. I'd rather repeat the function call than have to look at this,
but I recognize that that's a matter of taste.

 

[Bruce Wood]

Hi Cor,

What two optimizing phases do you mean?

I tested this in the Debug configuration without optimization checked in the properties window for
my VS 2005 project, and in Release mode with optimization checked.

Neither test optimized out the code.

Remember that after the compiler produces the IL, the JITter gets a
hold of it at runtime and transforms it into actual machine code, and
optimization takes place during the JIT compile, as well. It may be
eventually optimized out. We just now know that if it is in fact
optimized out the optimization isn't at compile time.

Given this, though, it's probably safe to say that it won't be
optimized. It looks like the kind of thing that the compiler should
deal with, not the JITter.