Naming Conventions

If you don’t have standard naming conventions in your Xojo (or any other language for that matter) project you need to start NOW.  I mean it.  Open your IDE of choice and start looking at your variable names.  Can you tell at a glance what type of variable it is?  Better yet, can you tell what it does?  Or do you have a bunch of x, i, y, and z’s floating around in your code?

What about your TextFields?  Do you name them so you can tell their function or do you simply use the default name that the IDE gives you?  How do you tell the difference between TextField1 and TextField2?

Literally, the first thing I do when handed an OPC (Other Peoples Code) project is to look at the control names.  If I see TextField1 and TextFieldX I will almost always turn the project down.  But if I see txtName and txtAddress I know that I can figure out the code without constantly having to look at the Layout Editor.  The point is that controls are referenced in Xojo code all the time so if you’re naming your controls so that their function is obvious, the code will be obvious too.

The same goes with variable names.  I will prepend arrays with ar so that an array of MyClass will always look like aroMyClass.  My dictionaries always have dict in the front.  Colors always have c prefixes and so on (see chart below).

Do I use the occasional i, x, y and so on?  Absolutely, but they are throw away variables that are inevitably part of a loop of some sort.  If I’m using that variable for any other reason I will always name it something useful.

Variable names are important.  Rarely will you see me using iTemp as integer.  Instead, I’ll use iTempIndex which will at least tell me something about the variable.

I dare you to look at a project you did a year ago and open up any random method in it.  Can you read the code without referring to the Layout Editor?  I know that I’ve refined my own coding standards because of this.  If you’re not learning from your past mistakes why keep doing what you’ve always done?

I can hear some of you now.  Standards…Pft!  I don’t need no stinkin’ standards.  Think again.  I’m not here to tell you what those standards are just that you have them and that you are consistent about them.

Do what makes sense to you.  I looked at hungarian notation ( and I can see why people call it a different language.  While I’m sure it has many fine qualities it seems to make more work for me in figuring out what the variables are doing.  It’s way too complicated for Xojo.  For me, at least, simpler is better.  Plus, I’m not sure that a strongly-typed language like Xojo is in need of such strong naming conventions.

Using naming conventions for your controls and variables is an easy way to simplify your life and your clients’ life (if you’re handing code over).  Remember, you’re not just coding for the here and now, you’re coding for someone that will look at the code 6 to 12 months from now.  That someone might just be you!

Below is values right out of our new developer introduction document:

Variable Prefixes
Datatype Prefix Example
string s sName as string
integer i iCnt as integer
double d dAverage as double
dictionary dict dictNames as Dictionary
date dtm dtmModified as New Date Assumes I care about the time
date dt dtToday as new Date assumes I do NOT care about the time
class reference o oMyClass as new clsMyClass
color c cHighlight as color
folderitem f fPic as FolderItem
private property m miCnt as integer
boolean b bVisible as boolean
memory block mb mbBuffer as MemoryBlock
window win winMain
class name cls clsMyClass
array ar arsNames() as string ardAverages() as double aroMyClass() as clsMyClass
Control Prefixes
Control Prefix Example
Pushbutton btn btnSave
Label lbl lblCaption
Listbox lb or lst lbPeople or lstPeople
StyleGrid sg sgPeople
TreeView tv tvSections
TextField/TextArea txt txtPassword
CheckBox cb or chk chkEnabled
BevelButton bb bbSelect
ComboBox cbo or cmb cmbUserType
PopupMenu pm pmState
ProgressBar prog progUpload
Scrollbars see example common practice to use vScroll and hScroll
Radio Buttons rb rbOption1
Canvas cvs cvsGraph
TabPanel tab tabMain
Toolbar tb tbMain
PagePanel pp or page ppSection
Menu menu menuPopup
Container Control cc ccDetails

9 thoughts on “Naming Conventions

  1. Excellent post. I came from a dynamically typed language and we used hungarian notation to help our team be able to cross-code applications. With Xojo I’ve adopted a more abbreviated naming convention similar to yours. I find it very helpful.

    I also like to spell out variables in full. The variable ‘iCnt’ is less clear in meaning to ‘iCount’ or ‘iContinuation’ or ‘iContainer’.

    Thanks for the post!

  2. Interesting post, I use a lot of these. I find them very natural and easy to use and read. Also, they make the type-ahead menu shorter and easier to use.

  3. I use a lot of the same ones.

    Just a little note: I presume o stands for “object” so I would write that. Otherwise it is confusing to beginners that “class reference” abbreviates to o.

  4. Very interesting post. Having this convention typed out helps keeping the standard alive while coding. Thanks to BKeeney Software for sharing.

    • Variants are evil. Seriously. Implicit conversion is a *bad* thing because it can lead to very subtle (and wrong) datatype conversions and the compiler will never catch them. They also tend to consume a bunch of memory and are slow.

      While I can’t say we never use Variants we generally only use them in custom controls that need Tags (like the ListBox.RowTag) where you never know what sort of data we’ll need to stash in there.

      If you are relying on Variants in your code I would rethink your strategy.

  5. “Below is values right out of our new developer introduction document”

    Where can I find this new developer introduction document? Is this something available to the new developer or internal to your organization? I couldn’t seem to find it in the Xojo documentation. Thanks for the naming convention you posted – I am a fan of standardization.


Comments are closed.