CamalCase everywhere.
Project items: clsClass; frmWindow / frmContainer; modModule; mbMenubar; pgWebpage.
Code: variables prefixed with some form of generic type indicator. objVar, strVar, bolVar, intVar, varVar, etc.
I only prefix controls with cn, so: cnButton, cnPopup, etc.
For years I did not prefix things. Then I had to on a client’s project and part of it stuck. What I like is that the prefixing reduces the number of meaningful names you have to come up with. Example:
Dim objWindow As Window
For i = 0 To c Step 1
objWindow = Window(i)
Next
It’s pretty clear what objWindow is, but you don’t have to be creative (TheWindowImLookingFor) nor are you tempted to use single characters that mean nothing a dozen or so lines down (w). Another example:
Dim objData As New clsData
Dim strData As String = objData.ToXml
Each item is clear, but you don’t have to create or remember any names, and the relationship of the items is obvious. 2-3 character prefixing seems to help auto complete so I stuck with that rather then single character.
The part that did not stick was separate prefixes for controls. That never seemed to reduce the work load or clarify anything, it only increased the work. When I’m writing or scanning code I want an indicator that it’s a control on a form, but beyond that I don’t care.
Oh yeah…mProperty for private/protected properties, otherwise Property and Method. For some reason I really don’t like prefixing class properties and methods. I use m on private properties because that’s what Xojo does when you make a computed property. (Why m btw? Why not p?)
I didn’t really use the project item naming conventions in Web Custom Controls because I don’t think most Xojo users are used to them.
