Components naming convention

This is somewhat related to Ignition, but also very broad across different platforms and languages. I’m creating an internal company document for naming conventions for components and controls. I was curious if anyone has a list already created that they would be willing to share. I would like to keep things as generic as possible, so control naming in .NET, for example, would be close to component naming in Ignition.

Just a few I have so far:

Comp/Ctrl Name
Button btn
Checkbox chk
Database db
Document doc
Dropdown/Combobox cmb
Form frm
Grid grd
Group grp
Image img
Index ix
Label lbl
List box lst
List View lvw
Panel pnl
Picture box pic
Progress bar prg
Slider sld
Tab Strip tab
Textbox txt
Timer tmr
Tree View tre

Let me know if I’m off base here. Thanks in advance.

Sorry. Microsoft code conventions make me want to puke. Components have a type. It is visible in the components properties. A prefix is redundant, and can cause extra work (or bugs) if you later decide to substitute a different component type for a particular element (you have to rename in scripts, etc).

Just say no.


So you just use the generated name the software gives?

Of course not. I name components by their application role. That may retain part of the default name, but often includes a DB table or column name, or the base name of a UDT element.
Groups and containers also get application-relevant names, which often reduces the length of component names within. Brevity is a win, especially when hierarchies are logically organized.

Thanks @pturmel for the comments.

I’m going to go out on a limb and say that your list of names is acceptable in some circumstances. What you are suggesting is a form of “Hungarian Notation”. However there are two “flavors” of this notation:

  1. Semantic type - Whereby the prefix identifies the usage of the object that it has tagged (also known as Apps Hungarian).
  2. Storage type - Whereby the prefix identifies the data type of the object that it has tagged (also known as Systems Hungarian).

And example of the Semantic type would “numberItems”, while the same variable could be represented as “intItems”. There is general consensus that the Semantic type adds useful information, and that the Storage type should burn in hell at the very least as adds noise to understanding the semantics of the code. (EG I don’t care what the underlying data type or a variable is; all I care about is what it does.)

You seem to be suggesting the Apps form of hungarian notation. This can be useful in disambiguating two related objects (EG the text box that contains the user name, and the username itself). I say “can” because if your toolset and/or language supports strong typing then there is no need for it (EG in .Net it’s pretty well impossible to use a string in place of a text box object). Thus at that point you should skip any tagging of variables and just name things after their functionality, not what type they are.

(I’d also suggest that with the proper toolset changing the type of an object is not an issue as most modern toolsets such as Visual Studio provide a plethora of refactoring tools that make life easy)

The problem comes when your toolset and/or language doesn’t support strong typing (EG Python). In this case the correctness of operations between different objects is left up to the programmer which can lead to subtle bugs if the entire code base can’t be held in a persons memory at one time, and they lose track of what means what. However for small blocks of code in Ignition scripts you shouldn’t run into that issue.

Thus the recommendation for and against any sort of Hungarian notation comes down to: It depends.

Some resources you could read about the pro’s and cons are:
What’s up with Hungarian notation (Eric Lippert)
Making wrong code look wrong (Joel Spolsky)
General naming conventions (From Microsoft - see the “Do Not Use”)
What is the appeal of Systems Hungarian? (Software Engineering Stack overflow)

However I do applaud you for actually attempting a coding standard! Making your code conform to any sort of standard is a huge step up!


I wasn’t going too deep on this, basically, instead of using the software generated name, I wanted to make some kind of standard for neatness sake. I see Phil’s point, use a name that isn’t really tied to the component. At any rate, my goal is that everyone under the same roof do the same thing. But, it’s also nice if there is an industry standard to go off of, then you could almost follow anyone. Either way it’s not a difficult thing, just something nice to have, IMHO.

Hear, hear!