[RESOLVED] VB2008 Express - Menu naming

[rasinc]

I've finally started doing some real work in VB2008 and am using the Express edition at this point. I've started just by doing some basic form layout stuff mimicing some things I have done in VB6. BTW, I only picked up VB6 by reading and modifying some samples found on the internet (including here). I have never been really trained in all the basics (taking a VB2008 course now though).

I have set up a menu by adding a MenuStrip. I left the default name alone and then added some menus like File|Exit and Help|About.

I was then doing some adding of code for File|Exit and started looking at the names. In VB6 I had named my File menu mnuFile and File|Exit was mnuFileExit. In VB 2008 it seems the defaults are very long eg. FileToolStripMenuItem and ExitToolStripMenuItem. As long as I remember one is file and the other is exit, the intellisense brings them up fairly quickly.

However, I am used to typing the short names and was thinking it might be worthwhile to use the shorter names if I decide to later make changes to text based on language. The intellisense will group the mnu objects together so I see all at once when doing data entry.

So the main question is should I change the default names to something shorter to ease access down the road or does it really matter? Of course as I reread this, I have a feeling the answer is, "if you want to, do it, if you think it will make life easier".

TIA rasinc

[ForumAccount]

My opinion is to name it logically. Setup a naming schema for yourself that you always follow. For MenuStrips I do:

tsm[Text]_[SubItemText]_[SubItemsSubItemText] which would basically be the path of the ToolStripItem. Yes that can get long but, as you said yourself intellisense will bring up options for you so use a descriptive name and then pick it from intellisense and press space. This way you don't have to worry about remembering what you named the controls.

[jmcilhinney]

The recommendation for naming anything in .NET is to use a name that indicates the thing's purpose, not its data type. Sometimes the two will intersect but your main consideration should be purpose.

Also, the use of Hungarian notation has been oft-debated and I am dead against it. I believe that consistency is extremely important so, if you're going to use Hungarian notation then you should use it all the time, but there are just too many types in the .NET Framework alone, never mind third party and your own types, to make that practical. There's just no way to remember all the prefixes or ensure that every type has an intuitive and unique prefix. Then there's the folk who put "obj" in front of 90% of their variables. Seriously, what's the point of that?

Of course, what you do is up to you but there's literature on naming conventions provided on MSDN. I can't see any reason to stray from those. For instance, I can't see how grouping all the menu items together in Intellisense is an advantage. If I'm looking for a menu item that does something specific, why does having other menu items close by in the list help me out? It just means I have to type "mnuf" to get to the file menu item instead of just "f".

[rasinc]

Thanks for the input. I also have a big need for consistancy in everything I do. More consistency, more speed. More speed, more work done. I've proven this to myself too many times to give it up now. This is one of the reasons why I asked the question. I am evolving my skills into a new language and while I have been consistent with the Hungarian notation in the past, I know the new language is different in many respects and I want to be consistently using a "correct" notation (yes, I did know there is a bit of discrepancy of what is correct).

For example ForumAccount mentions Menu Strip then uses tsm as the prefix (for Tool Strip Menu), but I was able to translate the two easily enough (even though I am not quite comfortable with all the terminology in VB2008). While the terminology is inconsistent in my mind, the use of tsm all the time while referencing those objects is consistent and probably helps in the long run while reviewing the code. This is why I was considering using this concept because of future maintenance.

If I will be maintaining a program there is a solid chance I will not remember what I named objects over time (even though I do use the same names between programs for the same thing like mnuFile for all File menus). I have not had enough experience in VB2008 types to see all the different types you are refering to, jmcilhinney but if I don't remember a name and do remember a prefix, at least it would reduce the list in intellisense to give me a shot at finding something faster (at least I think so in my own mind). But it is a good point that I should check the updated naming conventions in MSDN before I start doing lots of programming and start with a good footing and use the same concepts all the time. I doubt I have looked at naming conventions in 8 years. While I was really just thinking menus in this thread, it is a good point that this really refers to all objects. And I agree with you about the obj prefix

I appreciate you both taking the time to respond. These are the types of thought provoking concepts I was looking for.

[jmcilhinney]

If "tsm" stands for "Tool Strip Menu" then what would you use for a ToolStripManager?

[SJWhiteley]

Personally, I name menus with the prefix Menu and the functionality provided. So the file menu is MenuFile, the sub menu item called save would be either MenuSave or MenuFileSave, but it's application specific.

I like the prefix Menu, simply because it means that I know which 'save' I'm looking at (there may be a save button, too, which will be called ButtonSave).

I also don't see the advantage to hungarian notation - although I use that with local, temporary, variables in a method. Member variables and methods are never hungarian notated.

Even though you can name variables what you like, the reason for establishing a 'standard' method is so that everyone who looks at the code can understand clearly what is going on, what method does, what a variable is for, without having to have a 'decryption code key', or have to read the functions code to understand what it's doing. Also, tomorrow, you yourself will forget (another reason for use of liberal comments - personally, I like a 2:1 ratio of comments to code, but at least 1:1).

[jmcilhinney]

Personally, I name menus with the prefix Menu and the functionality provided. So the file menu is MenuFile, the sub menu item called save would be either MenuSave or MenuFileSave, but it's application specific.

I like the prefix Menu, simply because it means that I know which 'save' I'm looking at (there may be a save button, too, which will be called ButtonSave).

I also don't see the advantage to hungarian notation - although I use that with local, temporary, variables in a method. Member variables and methods are never hungarian notated.

Even though you can name variables what you like, the reason for establishing a 'standard' method is so that everyone who looks at the code can understand clearly what is going on, what method does, what a variable is for, without having to have a 'decryption code key', or have to read the functions code to understand what it's doing. Also, tomorrow, you yourself will forget (another reason for use of liberal comments - personally, I like a 2:1 ratio of comments to code, but at least 1:1).

Excuse me waiter, can I see the menu dessert please? Also, my companion would like to see the menu drinks. I'll then be leaving by the door front.

[SJWhiteley]

Excuse me waiter, can I see the menu dessert please? Also, my companion would like to see the menu drinks. I'll then be leaving by the door front.

Damn, you spotted the flaw...

yes, it is backwards, but it's really a compromise between sorting/finding the right item/method you want to work with and describing the functionality of that method. But then, there's no difference between DoorFront and FrontDoor; both are valid descriptions containing all the information necessary. Either way, it works for me.

[rasinc]

Thanks for the information added