[RESOLVED] How to alter VB.Net Naming Standards

[jlmacfad]

Whenever I create a variable or control name I try to stick to the standards I've always used. The first three characters are the recognized abbreviation of the control type or variable datatype. For example "txt" followed by a meaningful name for a TextBox. Also I use "btn" as the prefix for a Button.

I find that I am getting compiler warnings for certain instances of button controls telling me they should start with a capital letter. This only happens for a few buttons and no other controls.
Is there a way for me to examine the Naming Standards used by VB and possibly stop these warnings

Thank you

[jmcilhinney]

You should stop using that naming convention and then the problem does away. What you use is up to you but Hungarian Notation, as that is called, is pretty much outdated. That's mainly because it was created back when there were only a few types to use. In a VB.NET app you have access to hundreds - probably thousands - of types. Are you really going to use a different abbreviation for all of them? The biggest issue I have is that many people use a reasonable prefix for a few common types and then 'obj' for everything else. You should only reasonably use 'obj' for a variable of type Object so using it anywhere else is useless at best and misleading at worst.

It is my opinion - and Microsoft's recommendation - that you don't use such prefixes but, instead, use a descriptive name for every variable, etc. That would mean that, for example, a String variable to store the given name of a person would be 'givenName'. Is there really any reason to specify that is type String? You can simply mouse over it in your code at any time to see what type it is but, apart from that, what reasonable person would expect that a variable to store a given name would be any other type? For controls on a form, use names like 'okButton' and 'givenNameTextBox' rather than 'btnOk' and 'txtGivenName'. Generally speaking, what the variable is for is more important than what type it is so having that at the start of the name is the more reasonable option. Even if you have multiple controls relating to the same thing, e.g. 'givenNameLabel' and 'givenNameTextBox', there will usually be fewer matches when you start typing than those that would match by type. Yes, it's a few more characters to type when you use such names but there are also times that it will be fewer characters. You only ever have to type the full name once anyway, thanks to Intellisense, so the few extra characters shouldn't be an issue for anyone.

[jlmacfad]

Thank you for your response. While your suggestion will, probably, solve the immediate issue you didn't answer the underlying questions...#1 why did all controls not generate similiar compiler warnings and #2 is there a way, in VS, to access the naming standards being used by the compiler

[jmcilhinney]

you didn't answer the underlying questions

That's probably explained by the fact that I didn't try to. If you got warnings for some things and not others then it's because there's some difference between them. We can't see your code so we can't see what the difference is. As for how to view/edit the rules, I use ReSharper and it changes the way VS works regarding stuff like that, so I often don't know what's ReSharper and what's VS.

[techgnome]

Thank you for your response. While your suggestion will, probably, solve the immediate issue you didn't answer the underlying questions...#1 why did all controls not generate similiar compiler warnings and #2 is there a way, in VS, to access the naming standards being used by the compiler

It's not the compiler that's actually doing it. It's something else that's in the way. Likely a plugin or addin like ReSharper, or FxCop, or something. It saw something in your naming convention that it didn't like and flagged it. The compiler itself doesn't give two flying figs if you call a test box t, txt, txtBox, or BobsMyUncle. So, yes, there is a way. Find out what is flagging it and change the rules... or find out what the rules are and play by them. Either way should be fine, it's your sandbox.

-tg

[i00]

Just my two cents.. not really an answer:
Personally I can't stand the small case for local variables and the capital for the public ones ... I use _ prefix for local ones (in C# too)...
jmcilhinney, I love txt, btn etc prefixes for interface elements they are the ONLY thing that i use Hungarian Notation on though, I hate it on anything else !

Kris

[jmcilhinney]

jmcilhinney, I love txt, btn etc prefixes for interface elements they are the ONLY thing that i use Hungarian Notation on though, I hate it on anything else !

I doubt that you could provide an explanation for the inconsistency that I would find satisfying. I doubt that you would care too much about that thought.

[i00]

I doubt that you could provide an explanation for the inconsistency that I would find satisfying. I doubt that you would care too much about that thought.

My reason is the same as why I prefer blue over black, and others would prefer the other way ... i.e. there is no logic is it just what I prefer
My last 2 jobs have also programmed with the same conventions prior to my arrival ... I do admit that it is inconsistent .

Kris

[ident]

While I am not a professional I try to abide by hide standards. Standards I apply throughout every class, every project. Microsoft makes guidelines, but they are simply that. You or know one else has to follow anything they say. IMO as long as your team, or yourself follows the same guidelines throughout a project then I can not see anything wrong with that.

I used abbreviation like txtWhatEver, btnWhatever back when I first bought vb6 in 1997 from pc world at 13. I can't stand that. Have not done for many years. Me personally If i had a textbox that required a username it would simple be UserName. I would not include any textbox reference.

The Intellisense is not from early 2000s anymore, descriptive names are fine. But thats my opinion. I program solo so as long as i follow standards throughout then it is a standard.

[jmcilhinney]

Me personally If i had a textbox that required a username it would simple be UserName. I would not include any textbox reference.

My issue with that is that the name implies that it actually contains a user name, rather than a control for the entry and display of a user name. If you were to then have a String variable that was to store the user name entered via that TextBox, what would you call that? If you had a Label beside that TextBox that indicated to the user what the TextBox was for, what would you call that? I'm guessing that the latter would be qualified with the type of control, but then the TextBox wouldn't. You're right that personal preference is a big driver but I would suggest that consistency should also be a goal. Qualifying some controls with their type and not others seems inherently inconsistent to me.

[ident]

But thats a if "if" we are looking for something to come up against it. I as my own team have never. I cannot justify focusing on what a team of likely your size issues comes up against.

I am so over the top anal with xml documentation and naming standards that I enforce on myself. My point was You do not need to follow ms standards. That was all. I was not suggesting that fits all. I was actually discourage about ten years ago not to include any control reference beginning or end of an control by atmawapons(sitten spitten here)

Btw i never said I name some controls with a type and the others I do not. I mentioned I followed that type back in the 90's to 2000s If I had a label of no value that represented a textboxs nature I would just set its generate member to false.

Tbh my opinion on that is kind of one sided as I have not worked with windows forms for years. Last 2 have been console. Completely get your point there was just to emphasize as long as you stick to your on standards robustly it is not a big issue imo from a lone programmer.

[topshot]

I doubt that you could provide an explanation for the inconsistency that I would find satisfying. I doubt that you would care too much about that thought.

The reason I do it i00's way also is so all controls of similar type are grouped together in the IDE drop downs so I can find the one I want faster. The main exception is labels that are only for GUI purposes, which I leave the default LabelXX.

[techgnome]

Following your standards and being consistent about is more important than what they are. That said... emergrd topshot... that labeling system for your labels would drive my CDO nuts.

But anyways... rather than go on about why I do what I do, I'll briefly talk about why I don't do what I don't do and why I fell out of love with the Hungarian notation.

A few jobs ago, they took the HN to the Nth degree. Everything in the UIX had a prefix... everything in the back end had a prefix. All the back end stuff had the normal stuff... But the front end took it several steps too far. First, it had the ux prefix. that denoted it as part of the user experience. then it had a prefix for what it was: tb for text box. Only we didn't use textboxes.... no... we usedt he deity forsaken infragistics ultra edit text box.... so already, before we've even identified the text box we've already had to type: uxuetb .... Drop downs, uxuedb ..... and these weren't simple forms... they're stuffed with boxes, grids, all kind of input forms, tabs... grids..... grids.... It took me working there just but a few weeks before I developed a distain for the HN. Now, when I have a grid that lists customers... it's a CustomerListGrid and it's data source is a CustomerList (List(Of Customer))....


If it's a duck.. it'sa duck... not brdDuck.


-tg
\