Variable naming conventions

I just found an old document I created more than a decade ago about variable naming conventions. I decided to create a post on my blog about it so you can read it and maybe share your thoughts about it :slight_smile: I find this quite interesting but quite evident, maybe we all use those conventions in an automatic way. For those who don’t, you really should.


And about naming the Controls, I usually set Listbox as LB. (and so on).

But when there are many controls in a Window, I tend to add a more meaningful name and use “prefix” to get the related Controls besides them in the Navigator.

As usual, you do what is best for you.

Good Lord, there’s only a couple of those I would consider. But it’s often said, any convention is better than no convention. Well, almost any :wink:

I second that.

Not so much variable names, but when it comes to Methods/Function or Stored Procedure names, I like to order the phrasing of the name in a way that groups related functionality together - at least as they would appear in alphabetical order.

In order like [ | ].

So for example:

  • DialogPreferencesGet
  • DialogPreferencesSet

As opposed to the traditional convention:

  • getDialogPreferences
  • setDialogPreferences

When it comes to alphabetical order, using the traditional convention, vou could have 20 or 30 names between your “get” and “set” related functions. Whereas placing the verb on the end of the name helps to group the names more logically.

At least I think so. I have one large Database project with over 2,000 Stored Procedures. Having this convention from the beginning has really helped save what little sanity I have left.

I’m quite accustomed to the naming conventions Bob outlined:

Like Tim shared our variable names are pretty standard. We don’t have the regimented method naming convention mentioned above. I do have experience with both method naming conventions and I tend to agree with @Scott Cadillac that using traditional Set/Get prefixes can separate the two methods in a way that are detrimental for easy reading. I like to use ComputedProperties when possible, to accomplish the same thing. However, that’s not always possible so the SomeMethodSet/SomeMethodGet works better, IMO.

Bottom line, though, is that you have to find the naming conventions that work for you and stick with them. You’re not using the conventions for today or tomorrow, you’re writing them for your future self six years from now. Or for the potential future programmer that you hope doesn’t have a time travel device to come back and keep you from making those awful mistakes. :wink:

I have a unique naming convention that people often ask me about when they read my open source code.

Public Class Properties:


Private Class Properties:


Inline Code Properties


Public Class Methods:


Private Class Methods:


I use the underscore to differentiate between properties of the class versus variables in the current scope. So:

// Set variable based on private Color property
Dim _tempColor As String
_tempColor = pColor

// Set variable based on public Color property
Dim _tempColor As String
_tempColor = Color

That way I can very easily glance at the code and have an intuitive idea what is being impacted by the code.

[quote=359764:@Scott Cadillac]I second that.

Not so much variable names, but when it comes to Methods/Function or Stored Procedure names, I like to order the phrasing of the name in a way that groups related functionality together - at least as they would appear in alphabetical order.


I generally do this as well not because I like it as a convention but seems the most efficient in terms of how the IDE presents the methods. I would likely use something else if I had to define the method signature myself in a full class file.

I used to do it the way you do it in your blog @Bob Keeney but I found I very much disliked all the types being grouped together. Like @Scott Cadillac mentioned I much prefer them be grouped by functionality.

My convention is pretty simple: look human. So the only prefixing I do is “m” for private properties for some reason. Just habit, not sure how I wound up on “m” but I did.

Controls and layouts do have a solid convention. I group by topic. So my controls will be named things like “FirstNameLabel” and “FirstNameField” so they show up together in the navigator. I find it more productive that way, and the names feel more intuitive, to me at least. Layouts are similar, I’ll use “UserSelectSheet” or “ProgressDialog” for the same reasons. Grouping by the type is not as useful to me as grouping by the topic.

Because I more-or-less started coding with REALbasic (technically Perl was first though) I never really got into habits such as prefixing constants with “k” for example. The IDE groups them for me. It gives me icons. I can see at a glance that it’s a constant. If I try to assign a value to it, the compiler complains. So the prefix didn’t really provide me much advantage, and just served to make the code look less human.

For a long time, I was strictly lowercase only. For the past five years or so, I have been using titlecase. Again, the code looks more human that way. Never been a fan of camelcase.

I find it odd that I strive for human-looking code. But it is what it is.

A friend once asked me why a distinguished private methods and properties with a prefix, what the benefit was. After thinking of a few moments, my answer was a well-thought-out “shut up!”, so I stopped doing that. Now the only time I prefix a property is if it’s a shadow for a computed property.

Sorry you lost a friend… :wink: