🚀 go-pugleaf

"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