There was a message several weeks ago suggesting a new variable naming
convention.  Does anyone know where that info was from?  Were there any more
posts on that subject.

Thanks

Jim Ley

www.LeyTech.com

You can see lots of usage like that in the class library documentation.  I
suppose they have to bridge all kinds of users, from all kinds of language
backgrounds... but that doesn't look pretty to me <g>.

IMO it's more useful to stick to with what's been proven in for your type of
development in the past.  You may be using a new toolset, but low level
quality issues will be the same as always.

The best practices you see out there for larger scale team development
include some explicit scope and type declarations.  Many of those best
practices were based on what Microsoft PSS suggested for VB development a
few years ago.

Justification: Programmers who don't know the scope and type of the
variables they are dealing with may rely on the compiler to catch problems,
but many subtle mistakes can escape this way.  That's even truer with the
.net changes.  Later, they will be much harder to find and fix.

(special note: folks who write class libraries, support tools, magazine
articles, etc., can do what they want.  OTOH they aren't well positioned to
prescribe what works best in the large scale <g>.)

By having "reserved fields" of fixed size in a prefix, you get past the
parsing quicker and into the thinking.   The core of that is often a 3 char
type field, as suggested by PSS originally, and 1 char for scope.

 e.g. mstrLastName = Member of type string used to hold Last Name,
strLastName = local var ...
        vstrAddress  = string param passed in by value... so every time we
deal with it, we are reminded that changes we make will be isolated from the
caller's scope.
    ..etc...

- 1 char SCOPE lowercase (if missing, scope is local)
    m = member, s = static in the trad VB sense, r = param by ref, v = param
by val.  New: something for shared, maybe "h", or upper "S"?
- 3 char TYPE lowercase (use PSS as basis.
   - Trad GUI objects mostly with the same names (lst for listbox, txt for
textbox).
   - trad intrinsice types, mostly the same as before: int (tho it means dif
f now!), lng, byt for byte, str for string. Whoops, this last one leads to
CLR objects
   - CLR string now has methods etc, a CLR library class, but why not still
call it "str", it's used so much. That leads to other TLAs for the few most
commonly used CLR classes, yet TBD by usage.
   - for the the "less used" 95% of CLR classes, "clr" might be good enuf
adding something in the Name to tell you the real type.  That's similar to
"obj" for an object of a class you provide yourself.  Although if I create a
class I use a lot, I invent a TLA for it's type as well.

  ... follwed by a descriptive usable "name" derived similar to PSS rules
basically, like "LastName"

Anyway that's the kind of usage I'll be looking for.

regards
Richard.

This is a bad way to name stuff. The use of a scope prefix is just annoying.

It's like naming all the classes Csomething. It offers no advantage, and it
makes it harder on the person using the library because everything is listed
under 'C'. Using r or v is also silly since intellisense clearly shows you
how it's being accessed. All these 'decorations' are simply not needed.

Hungarian notation was invented for C, a language with pointers to pointers
and no type safety. Back then, it has hard to figure out how a variable was
to be accessed because there was no context and so many different ways to
dereference it. Now that we have classes, strong typing, and no pointers, we
can use the context to determine the scope and leave the name for describing
semantics.

Note:
I am referring to the naming of public items. Classes, Properties, Methods,
Events, and Parameters. Stuff that other people have to see. For internal
items, I agree with the use of general type characters (n, s, b, o) and the
m (or m_) notation.

--
Jonathan Allen

My shop considers that to be a poor way to name things. We use the
following...

n = numeric
s = string
b = boolean
o = object

This way, if we change something from a Integer to a Long, we don't have to
rename everything. Besides, all numbers are used the same way.

In addition, Public names (classes, properties, methods) have NO decorations
what so ever. We find that it makes the declarations hard to read without
offering any additional information.

--
Jonathan Allen

The framework has a section on naming conventions...

.Net Framework Developer Specifications -> .Net Framework Design Guidelines

--
Jonathan Allen

Jonathan, Richard,

    I just got back on-line.  Thanks for the answers.
    Can I find
        > .Net Framework Developer Specifications -> .Net Framework Design
Guidelines
    on MSDN?

Thanks

Jim

http://msdn.microsoft.com/library/default.asp?URL=/library/dotnet/cpa...
or__net_framework_design_guidelines.htm

--
Jonathan Allen

Jim,

That looks like something I posted a while back. But it had nothing to
do with naming conventions. The list above is the new type characters
used to explicitly set the type on a constant in your code,

For example, the following two lines are equal

Dim a As Long = &H80000000&
Dim b As Long = &H80000000L

You can see what difference they do by executing this code

Console.WriteLine(1#.GetType.ToString())
Console.WriteLine(1!.GetType.ToString())
Console.WriteLine(1&.GetType.ToString())
Console.WriteLine(1%.GetType.ToString())
Console.WriteLine(1D.GetType.ToString())
Console.WriteLine(1R.GetType.ToString())
Console.WriteLine(1F.GetType.ToString())
Console.WriteLine(1L.GetType.ToString())
Console.WriteLine(1I.GetType.ToString())
Console.WriteLine(1S.GetType.ToString())
Console.WriteLine("1".GetType.ToString())
Console.WriteLine("1"C.GetType.ToString())

Matt

============================================

What's the risk when programmers aren't totally "crisp" on exactly what they
are doing with variables?  If you track issues/resolutions/costs, IMO you
find this is a significant and avoidable cost.

Why would you change a integer variable type, unless there was a programming
issue with it?  Don't you think that might be relevant for your coders to
know about?

Only issue with "Renaming" is source control AFAIK.  But use some messaging
like WinPopup (or even email, if everyone keeps it open).... tell the coder
"check that in for 1 minute while I do some renaming."

(
On the specific issue of integer types, there is a rule "Only Use Long"! <g>

In my Delphi days I was convinced by one of Delphites that using anything
but the long type for general integers should need a special exemption from
God.  Updating that advice to dot-net, there really is no advantage to using
something smaller than Long in most cases... only risk that it may suddenly
prove too small someday, and inefficiency in the meantime.
)

----
On general naming conventions, you don't find a lot of agreement, that's for
sure.  Some feel strongly against any conventions, some like type but not
scope, some only "fuzzy" typing like yours where n could mean Integer, or it
could mean long, or byte I suppose.  They all seem to feel strongly about it
though, don't they? <g>

But there are in fact many shops who do more precise naming than your shop,
who have proven to their own satisfaction that fuzziness is only a risk and
eventual cost..

Nuff said on naming by me... <g>

regards
Richard.

The goal of that article is consistency of public APIs... a completely
distinct issue from internal naming.  E.g., it advises strongly to avoid
specifying any types at all! (the same type may be referred to differently
in VB.net or in C-sharp of course.

(In well managed projects, Application Programming Interfaces are agreed,
documented and virtually "written in stone" in the early stages because they
are fundamental to everything else....that helps protect against "type
confusion" in APIs.)

In a normal installation of beta1, from Start Menu item:
MSDN For Visual Studio.Net
   / Visual Studio.Net Beta 1
      / .Net Framework SDK
         / .Net Framework Developer Specification
           / .Net Framework Design Guidelines
             / Naming Guidelines

regards
Richard.

Don't you mean Integer? Long is now a 64 bit number. (If so, I do agree with
you.)

The point is that it doesn't matter if it's short, long,, or double. In all
cases I am manipulating them the same way. I am relying on the person who
declared the variable to know what format he needs.

Never byte, our method isn't that 'fuzzy'. Out notation dictates use, and we
never use bytes for storing numbers.

Undoubtedly. That is why need a reasonable standard for external names.
Internally, I could care less what they call stuff. It's when I have to use
redundancies like MSMQ.MSMQQueue or any of Win32's atrocious parameter names
that I get annoyed.

--
Jonathan Allen

Integer: Yeah, I said "updating that to dot-net", and then I forgot to
update it <g>.  It'll all be second nature I guess, but it's hard to imagine
just yet. <g>

Whew, that frankly sounds a mite shoddy to me.  I would refuse to work with
another programmer's variables if he didn't commit to what type and scope
they were, and there was no process to communicate all changes to that.

Otherwise, it just makes for good war stories...  the time Bob changed the
type from integer to long, while Joe had copied it to an integer for a loop
and nothing went wrong til the release...

Some people like war stories like that, sounds like this practice will
generate a few for your shop <g>.

regards
Richard.