🚀 go-pugleaf

"Bob Dawson" wrote
> section, but I don't get a sense that there's any real concensus for the
> layourt of CSharp classes. What standards do people use to judge a
> well-organized class?

For those who don't know what I'm referring to by the variability of current
available style guides, consider

http://www.sharpdevelop.com/TechNotes/SharpDevelopCodingStyle03.pdf
http://www.bellware.net/documents/CSharpCodeStyleGuide_v1.2.pdf
http://www.tiobe.com/standards/gemrcsharpcs.pdf
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp
http://home.comcast.net/~lancehunt/CSharp_Coding_Standards.pdf
http://www.irritatedvowel.com/Programming/Standards.aspx

bobD

"Bob Dawson" <RBDawson@prodigy.net> a �crit dans le message de news: 
44b0539d$1@newsgroups.borland.com...

| 1. What are people generally using for a style guide? Two issues are 
really
| puzzling me

You have already mentioned the MSDN guidelines that seem to be the "norm"

|  a. Case sensitivity. As a long time non-case sensitive Delphi user, I 
tend
| to hate code like
|    ThisClass thisClass - new ThisClass();
| or property Something implemented with private field something, but that
| does seem to be widely accepted, and the idea of 'UpperCase means
| Class/Struct; lowerCase means instance' is at least a consistent standard
| (though how it explains Something/something escapes me), so maybe I could
| get used to it if I just gritted my teeth for a while.

In that case, ask Rudy to fit you a guard to protecty your teeth :-)

I have found that following the camel case convention for variables and 
private fields makes for very easy reading, making it very obvious what is a 
type and what is a value.

What can get a little confusing is when you get a property with the same 
name as the type it represents. A common example is DialogResult which is a 
type and the name of the property of that type !! This kid of thing can 
sometimes be avoided, but even if it can't, you get used to using code 
insight to get help on apparently ambivalent cases.

| b. Code organization. What rules have other Delphi folks adopted? In 
Delphi
| for me it's always been private/protected/public, alphabetical within
| section, but I don't get a sense that there's any real concensus for the
| layourt of CSharp classes. What standards do people use to judge a
| well-organized class?

The common advice for this is to use private/protected/internal/public for 
everything except methods which should be grouped according to functional 
area.

Using regions is a great help and one use I make of them is to contain 
something like an event and its related field/caller.

e.g.

  public class PropertyBag : INotifyPropertyChanged, ....
  {
    ....

    #region INotifyPropertyChanged Members

    private PropertyChangedEventHandler propertyChanged;

    protected virtual void OnPropertyChanged(object sender, 
PropertyChangedEventArgs args)
    {
      if (propertyChanged != null)
        propertyChanged(sender, args);
    }

    event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged
    {
      add { propertyChanged += value; }
      remove { propertyChanged -= value; }
    }

    #endregion
  }


|  I'm willing to give up my Delphi prejudices and write CSharp as
| CSharp--but the various style guiides I've read seem to vary quite a bit 
in
| their recommendations. I wonder if a winner is emerging.

I feel that following the same style used in the MSDN docs for their 
examples makes it a lot easier for those who will look back on your code to 
understand it.

| (simple and narrow)
| 2. Most of the CSharp text I've looked at all explain that string is an
| alias for System.String, int is an alias for System.Int32, etc. And the
| advice is almost universally to use the CSharp aliases rather than the 
built
| in System types. But nobody ever says why. So why? It bugs me especially
| since I'm trying to get used to the 'UpperCase means Class/Struct; 
lowerCase
| means instance' rule, then told to use lower case alias for all the value
| types. Where's the consistency to that?  grumble grumble <g>

I must admit I use the aliases, but I really couldn't say why I prefer them, 
it just sort of feels better ?? :-) In any case, syntax highlighting marks 
them as reserved words and I feel this can give quicker recognition of the 
"system types"

Joanna

-- 
Joanna Carter [TeamB]
Consultant Software Engineer 

Bob Dawson wrote:

> 1. What are people generally using for a style guide?

I use one based on the MS guidelines, but which deviates in areas where
I thought it made sense to do so in order to provide better
interoperability with languages such as Delphi.

http://dcleggsblog.blogspot.com/2004/03/c-naming-standards-as-c-pioneer-
at-our.html

or 

http://tinyurl.com/6fccb

-- 
Cheers,
David Clegg
dclegg@gmail.com
http://cc.borland.com/Author.aspx?ID=72299

QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com

"Heh Heh Heh! Lisa! Vampires are make believe, just like elves and
gremlins and eskimos." - Homer Simpson

"Joanna Carter [TeamB]" wrote
>
> In that case, ask Rudy to fit you a guard to protecty your teeth :-)

'fraid you were going to say that ...

> I have found that following the camel case convention for variables and
> private fields makes for very easy reading, making it very obvious what is
a
> type and what is a value.

Actually I am starting to grok that, which is part of why using 'string'
rather than 'String' bugs me. I'm still mulling over fields though: order of
current preference

String mFirstName
String firstName

Both m_FirstName and _FirstName are right out.

Despite MS's guidance otherwise, using a form of RPN--but now to indicate
scope rather than type--seems reasonable to me, with

mSomeThing = private field
aSomething = method param
tSomething = local var

't' for temp, but not sure about that last one. 'm' for method variable is
what I'd want, but that's taken as member variable. May go with m, t, and
procedure level variables unmarked.

> What can get a little confusing is when you get a property with the same
> name as the type it represents.

MS's recommendations in this area are quite obviously C#-centric.

> The common advice for this is to use private/protected/internal/public for
> everything except methods which should be grouped according to functional
> area.

But the whole thing is much more complicated of course. For example

All class stuff before all instance stuff?
Constructors always before any other methods?
Methods before properties, vice-versa, or all intermixed?
And Events?
Where to nested classes go?

Whats the over all sort priority?

class stuff then instance stuff, then within those
  --visibility
      --type (field/constructor/method/properties)
          -- functional group
              -- alphabetical?

Is a nested class treated as just another declaration type, going after
fields and before constructors

> Using regions is a great help and one use I make of them is to contain
> something like an event and its related field/caller.

But events are generally public, the related field probably private--so if
you're sorting by visibility how can they be together?

> I feel that following the same style used in the MSDN docs for their
> examples makes it a lot easier for those who will look back on your
> code to understand it.

Would that the different books that MS publishes all followed a consistent
style. They don't (Richter, for axample (CLR via C#) declares strings as
String).

> I must admit I use the aliases, but I really couldn't say why I prefer
them,
> it just sort of feels better ?? :-) In any case, syntax highlighting marks
> them as reserved words

a point against them: 'string' is a type, not a reserved word like 'else'

bobD

"David Clegg" wrote
>
> I use one based on the MS guidelines, but which deviates in areas where
> I thought it made sense to do so in order to provide better
> interoperability with languages such as Delphi.

What you remark on in your blog all generally falls into an area where MS's
guidance doesn't seem to be carrying the day: the lack of scope marking on
private fields. Or what might be termed an RPN of scope. Seems to me that m,
_, or m_ are doing pretty well in the general press.

"Do not expose a property with the same name as its underlying type."

Rock and a hard place on this one. Delphi is easy because TFont --> property
Font, but there being no type marker in C# except the casing, the
declaration of a property (arguably a public instance reference) should
really be the type name in camel case--except that that's probably what the
internal field is. in the translation from class/type (PascalCase) to
property to field (camelCase), the middle term has no where to go.

bobD