What notation do you guys use for control naming?

Hey guys i know most people still use hungarian notation for naming controls, but some people disapprove of it. I'm wondering for the ones who don't use that notation, what notation do you use normally for naming controls and components?

TheGroupOfTheControl_TheNameOfTheControl

So

About - tab page / group
About_Authors - just something in the group
About_Translators - just something in the group

I don't put the type of variable inside my names because I do most of my work in C# .NET 2005, and it tells you the type of the control during the intellisense.

And if i'm not using C# then i'm using PHP 4, and there variable types don't matter, i can easily make a int be a string or whatever.

In PHP most of my stuff is inside classes, and there is no point going

class About {
$About_Authors;
$About_Translators;
}

You just do

class About {
$Authors;
$Translators;
}

Yer I'm really against the hungarian notation, sure it would be good back 15 years ago, where memory was such a problem and you had to make sure that you don't run out of memory when assigning to your variables.

Yer...

I believe it's more important to put function before type, so in a form for collecting information I might have:

CustomerGroupBox
  CustomerName
  CustomerPhone
  CustomerEmail
  CustomerNotes
OrderGrid
    OrderNumber
    OrderDate
    OrderStatus
CancelButton
SaveButton

I care less about naming controls after the control type, and more about what they are used for. Of couse you can use camel case, or underscores, or whatever ... you get the idea.

sysrpl wrote:

I believe it's more important to put function before type, so in a form for collecting information I might have:

CustomerGroupBox
  CustomerName
  CustomerPhone
  CustomerEmail
  CustomerNotes
OrderGrid
    OrderNumber
    OrderDate
    OrderStatus
CancelButton
SaveButton

Lies!

You'd hate my source then I name my functions like so:

CustomerGet, CustomerUpdate, CustomerDelete, ObjectCreate, ObjectGet rather than GetCustomer, UpdateCustomer, DeleteCustomer, CreateObject, and GetObject.

I understand this naming system is "more correct" since it follows OOP's "Noun Verb" syntax rather than English "Verb Noun" which makes no sense until you've got the entire sentance.

In English, you say "Open the door", in more logical languages you say "Door, open".

W3bbo wrote:

I understand this naming system is "more correct" since it follows OOP's "Noun Verb" syntax rather than English "Verb Noun" which makes no sense until you've got the entire sentance.

Actually, most stuff I've read on OOP says you should use "verb noun" for actions (methods).

Sven Groot wrote:

W3bbo wrote:I understand this naming system is "more correct" since it follows OOP's "Noun Verb" syntax rather than English "Verb Noun" which makes no sense until you've got the entire sentance.

Actually, most stuff I've read on OOP says you should use "verb noun" for actions (methods).

But you call "Door.Open()" not "Open(Door)"

W3bbo wrote:

But you call "Door.Open()" not "Open(Door)"

ahh, sometimes I miss BASIC.  The non-visual kind. It was so simple, even if it didn't do anything useful. See if I remember correctly...

function open(object$)
   if object$ = "door" doorOpen = 1
end function
open("door")

If you have methods in the Noun-Verb form maybe you should consider creating an object, such as Customer, and then having methods on that.

Customer.Get() would be a static factory method for example.

Andrew Davey wrote:

If you have methods in the Noun-Verb form maybe you should consider creating an object, such as Customer, and then having methods on that.

Customer.Get() would be a static factory method for example.

That's the methodology I switched to for my latest project, but sometimes it's just easier to have all the methods in a single class.

W3bbo wrote:

But you call "Door.Open()" not "Open(Door)"

verb-noun:

door.OilHinge();

noun-verb:

door.HingeOil();

It should make sense to English speakers.

amotif wrote:

W3bbo wrote: But you call "Door.Open()" not "Open(Door)"

verb-noun:

door.OilHinge();

noun-verb:

door.HingeOil();

It should make sense to English speakers.

Bad example, the Hinge may be a member of Door, but it isn't the Door's responsibility to Oil the Hinge.

Maybe that kind of operation would be better done under Aspect-Orientated Programming rather than Object Orientated.

Here's a better example:

Oil.Lubricate(Door.Hinge);

I suppose you'd say the same of door.TurnKnob()?

That's okay, we all have preferences...


Besides, the point is about verb-noun order.

Hand.Turn(Door.Knob)
OilCan.ApplyTo(Door.Hinge)

This is starting to remind me of old Sierra adventures, where the parser would allow you to be correct "Use key to open the door" but often if you typed "Use key door" it'd also have the desired result.

amotif wrote:

I suppose you'd say the same of door.TurnKnob()?

That's okay, we all have preferences...

Actually, If I were using your methodology I'd change the casing:

Door.turnKnob();

Java's caseing system (Class, memberOf, NameSpace) makes a lot more sense than C#'s PascalCaseEverything.

As far as methods go, I typically use verbNoun.  Part of that is coming from a Java background--  Java exposes properties through methods like getName() and setName(string s), so that's the syntax I'm used to using.

For controls--  it tends to be pretty arbitrary.  I haven't done enough GUI programming to settle on a naming style really, but I tend to just use descriptive names w/o control types UNLESS it's something like a button.

I don't like how hard it is to change the name of a control in C# (it's buried in the properties sheet)...  makes me lazy (I get names like Button1 when working on smaller projects and don't change them).  Whatever happened to that quick property editor from Beta 1???