Re: Member Variables Naming Convention

Well I was going to look that up again but I see you gave me a trick
question. I just stated in the post you were replying to that I considered
references to controls a bit different than straight variables. Perhaps you
didn't read my entire post, eh? We were talking about member variables.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com


"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:O5LSBp4CHHA.4428@xxxxxxxxxxxxxxxxxxxxxxx
Hi Jonathan,

Hungarian notation isn't completely outlawed, however :)

Actually, in the Microsoft guidelines, it really is.

No, it's really not :)

Care to show me where Microsoft says that controls shouldn't be named with
prefixes such as "txt" or "lbl"?

(They are stored as private fields, you know)

--
Dave Sexton

"Jonathan Wood" <jwood@xxxxxxxxxxxxxxxx> wrote in message
news:ORhceA2CHHA.1224@xxxxxxxxxxxxxxxxxxxxxxx
Dave,

Absolutely. I mean, with C++, all strings should be wrapped in the _T()
macro and every run-time library routine and API appears to have both
an ASCII and Unicode version. Clearly, the .NET designers wanted to
clean things up a little and, presumably, thought simple names were
cleaner than all this Hungarian notation, etc.

Hungarian notation isn't completely outlawed, however :)

Actually, in the Microsoft guidelines, it really is.

I see no mention in the standards about the use of "txtFirstName", for
example, and I try to use this notation when I need to distinguish
between controls that would otherwise have identical names, such as,
"lblFirstName". Standardized prefixes are desirable, but I can live
without them.

Reference to controls is a bit different that straight variables. I
haven't see what the guidelines say about that.

Yeah, I can't do it. One thing (of many things) that annoy me about
.NET is the verboseness. Having suffered from carpel-tunnel issues from
time to time, I'm not going to prefix every occurrance of a member
variable with five additional characters. I guess that is as good as
any argument for me to adopt the "_" prefix as my personal style.

Not every occurrence of a member variable.

I think consistency is important. Using the this. prefix only some of the
time could get you into trouble.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com






.

Relevant Pages

  • Re: Member Variables Naming Convention
    ... Hungarian notation isn't completely outlawed, ... Actually, in the Microsoft guidelines, it really is. ... Reference to controls is a bit different that straight variables. ... for me to adopt the "_" prefix as my personal style. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Member Variables Naming Convention
    ... Actually, in the Microsoft guidelines, it really is. ... Hungarian notation isn't completely outlawed, ... this notation when I need to distinguish between controls that would otherwise have identical ... Having suffered from carpel-tunnel issues from time to time, I'm not going to prefix every ...
    (microsoft.public.dotnet.languages.csharp)
  • Hungarian Notation for Controls : Feature Request?
    ... Nearly everyone uses some kind of Hungarian notation for controls, e.g., my ... not be nice if the Forms Editor allowed you to set the prefix for every ... if you do a lot of GUI development. ...
    (microsoft.public.vstudio.general)
  • Re: To Hungarian or not to Hungarian
    ... standard found at: ... The argument was "Hungarian notation is no longer the recommended practice". ... The prefix should either be 2 or 3 characters long. ... Counter variables can be i,j,k but anything else gets a word - TempString, IsEmpty, AnimalType. ...
    (borland.public.delphi.non-technical)
  • Re: Windows controls naming convention
    ... I've been trying to "cross over" and start using the ... However, for controls, I'm finding that I like it ... better when the typename comes first (as with hungarian notation). ... As it is, I'm sticking to our standard, even though I like hungarian names ...
    (microsoft.public.dotnet.languages.csharp)
Quantcast