Re: CSharp Coding Standards
- From: Paul Werkowitz <newsgroups@xxxxxxxxxxxxxxxx>
- Date: Thu, 29 Mar 2007 17:10:45 +0200
Am 29 Mar 2007 03:44:26 -0700 schrieb auratius@xxxxxxxxx:
http://www.auratius.co.za/CSharpCodingStandards.html
Hello,
sorry, but much of this is a matter of taste. Like driving on the left side
or right side of the street. Different countries came to different
solutions.
Unfortunately, you did not give any reasoning for your "standards". For
example, *why* do you discourage the use of single character variable
names? Pls give arguments for your recommendations. Without that, your
"Standards" are no better or worse than any of the many other already
existing recomendations.
In *my* coding standards, the according passage reads: "Variables with
longer lifespan should have longer, more descriptive names. Variables with
short lifespan should have shorter names. Longer names express what the
variable stores ("Person", "UserId"). Shorter names express what a variable
is used for (e.g. i, j as loop counters)".
And: I personally strongly recommend the use of the shortest meaningful
variable names - but no shorter.
OK - see the difference? And btw, "temp" is in no way any better than "t".
Some of your recommendations are really questionable, and are frowned upon
by most professionals.
All member variables should be declared at the top, with one line
separating them from the properties or methods:
public class MyClass
{
int m_Number; string m_Name;
public void SomeMethod1( )
{}
public void SomeMethod2( )
{}
}
First of all, besides of personal preferences there are good reasons *not*
to write it like this. When we open a file to look at a class, we are
mainly interested in the public parts of the class - that is what we can
use. Private parts are implementation business and should not be visible at
all. From that follows that private methods and private variables should be
at the very end.
In *my* coding standards, I recommend to use the partial class feature to
separate public parts from implementation details. And I strongly recommend
to delegate work to the implementation parts. Sourcecode of public
functions should be very short.
About 80% Some of your recommendations are not even questionable, they are
plain dead wrong. I don't want to go into it deeper, but if someone wants I
can give more thorough analysis of many of the points. Simply one example:
Always mark public and protected methods as virtual in a non-sealed
class.
Sorry, but the other way around is correct: "Never make a public function
virtual", or "all virtual functions should be non-public (which leaves
protected, of course.)
Why? Because the publicly exposed interface of a class is defined by its
public members (functions, here.) Whether a class allows to "plug in"
another implementation for a certain service it offers, and how this is
technically done, is an implementation detail. Such a plug-in *can* be
realised by making a function virtual: we "plug-in" another implementation
by deriving from the class and overriduing the function. BUT - and thats
the important part - the *interface to the class* must remain the same. For
example, checking of preconditions should be in the public function. If
this were virtual, one could simpley derive and omit the checks..... no
good idea. (BTW, there are other techniques to plug-in functionality:
delegates are an example).
OK, one more.......
Assert every assumption. On average, every fifth line is an assertion:
object someObject = GetObject( );
Debug.Assert(someObject != null);
Sorry, completely wrong.
- if GetObject's contract says that it must return an object, then we do
not need to test it after the call. (Of cource, GetObject will throw an
exception should it find that it cannot fulfil its contract).
- but if Getobject's contract says that it can return null, then we
eventualy must write
object someObject = GetObject( );
if ( someObject != null )
{
...
}
etc.
My 2 cents....
Paule
.
- References:
- CSharp Coding Standards
- From: auratius
- CSharp Coding Standards
- Prev by Date: Re: Typed DataSets in VS2005
- Next by Date: Re: Values of Unknown Custom Attributes
- Previous by thread: Re: CSharp Coding Standards
- Next by thread: Re: CSharp Coding Standards
- Index(es):
Relevant Pages
|
