Re: Hungarion Notation is out but..
- From: "Jeff Jarrell" <jjarrel_NOSPAM@xxxxxxxxx>
- Date: Wed, 15 Jun 2005 20:00:19 -0400
thanks for the coming back to the original question. i share a similar
feeling with respect to HN and at this point feel its ok to prefix the
instance. I am not sure I can keep my team consistent that with naming that
only differentiates in terms of case usage (c# a different story). I think
i am going to go with "aUser".
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2334$yrbcFHA.2664@xxxxxxxxxxxxxxxxxxxxxxx
> Hello Jeff. It seems like most of the other posts have been focused on
> the merits
> of Hungarian Notation, but because I've found myself in the same dilemma
> as
> you, I'd like to give some input on the original question.
>
> So, if you accept Microsoft's recommendation to avoid HN, how to handle
> the
> following code?
>> dim User as new User
>
> I've found that in most cases, the code I am writing to access an instance
> of a particular class is in some kind of special context that can be used
> in
> the variable name. In other words, I use the type of operation being
> performed on the class to differentiate the class name from the instance
> name. For example, if the person is selecting a User from a ListBox, my
> variable name would be SelectedUser. If I'm getting ready to insert a new
> User into a collection, I would name the variable InsertUser.
>
> Now, admittedly, there isn't always an obvious choice for a "context
> prefix"
> (perhaps because you are writing code that intentionally handles the class
> in any context). Personally, I handle this in one of two ways. The first
> is just to use the My prefix, as in MyUser. Using "My" has always seemed
> a
> bit amateurish to me, but my aversion to HN is strong enough that it
> always
> wins out over any fear that my fellow programmers would make fun of my use
> of "My". The other way (which happens more as a result of my design
> rather
> than another way to avoid this naming conflict) is to imbed the logic
> which uses the instance in a method. For example, my code often contains
> functions in this format...
>
> Public Sub InsertUser(user as User)
>
> I personally am not a fan of C#'s case sensitivity, but VB.NET's case
> "awareness" can come in very handy in this situation. The Microsoft
> naming
> standard specify that parameter names be in camelCase (and "user" is in
> camelCase). So by following this naming standard you can differentiate
> the class name (User) from the instance (user).
>
> HTH.
>
> - Mitchell S. Honnert
>
>
>
>
>
>
>
> "Jeff Jarrell" <jjarrel_NOSPAM@xxxxxxxxx> wrote in message
> news:uHqUlP3bFHA.612@xxxxxxxxxxxxxxxxxxxxxxx
>> Hungarion Notation is out but..
>>
>> I am trying to keep the notion of naming things "it is what it is, name
>> it
>> that"
>>
>> Class Names are an interesting side. If we name them in a meaningful way
>> and then we name an instance of in a meaningful way there will ultimately
>> be a semantic collision.
>>
>> For example,
>>
>> In a VB6 way
>> dim oUser as new clsUser
>>
>> In a .Net way
>> dim User as new User
>>
>> When I read vb6 example, it jumps out at me whether I am refering to the
>> type or the instance. In the .Net way I am not sure from just reading
>> it.
>> (am I using a static function in a type or a function that uses an
>> instances).
>>
>> I am tempted to either suffix the type or prefix the instance. But thats
>> not in the spirit of .net now. Should I just get used to not immediately
>> recognizing the difference between an instance and a type?
>>
>> thanks,
>> jeff
>>
>
>
>
.
- References:
- Hungarion Notation is out but..
- From: Jeff Jarrell
- Re: Hungarion Notation is out but..
- From: Mitchell S. Honnert
- Hungarion Notation is out but..
- Prev by Date: Re: Why use properties?
- Next by Date: Listview Items help
- Previous by thread: Re: Hungarion Notation is out but..
- Next by thread: functions as parameter
- Index(es):
Relevant Pages
|
