CamalCase or snake_case, which do you prefer?

Having just returned to Xojo after a long stint solely with PHP I found myself using the more common PHP parlance of snake_case in my code. I’m just curious as to how people tend to format their code?

Traditionally in Xojo I had done the following:

Variables: startWithLowerCase
Private member variables:mStartWithLowerCaseM
Methods/classes: StartsInUpperCase

What conventions do other Xojo users use? Although I prefer snake_case it seems Xojo ‘prefers’ camelCase, at least from looking a their naming conventions (although there are some internal inconsistencies with variable names starting with capitals, etc).

Variables local to a method: startWithLowerCase
Private member variables: mStartsWithLowerCaseM
Public member variables: CamelCase
Methods/Classes: CamelCase
Constants: kAbcXyz

I use the same CamelCase for methods and public member variables because a lot of times a method can act like a variable or a variable like a method, thus when changing my class, the end user does not have to change their code. For example:

Person.Age vs. Person.Age … One could be a member variable, the other a method or computed property working off of DateOfBirth.

I don’t seem to have a preference between CamelCase vs. snake_case. I use what is the standard for the language I am writing in. To me, one is “word shift-letter word” and the other is “word shift-_ word”… Same amount of typing, same amount of stress on the hand.

camelCase all the way baby… Just my personal preference.


What day is it?

Variables declared inside a method: theWithADescriptiveName
Private/protected member of a class: pForPrivateOrProtected
Private member of a module: pAsForTheclasses
Public member of a class and protected member of a module: CamelCase
Module & Class names: zdAsInZaatarDigital
Constants: kConstantName
I avoid using the Global range in modules to enforce namespaces use and for array names, I’m using the plural form.

And I also like to put spaces after or before brackets, operator signs and I’m wasting a lot of blank lines. A lot…
BTW, I’m wondering if it would be possible to have half height blank lines in the code editor or with the printed code. Wouldn’t it be nice?

Camel case with pre-abbreviations - kind-of stuck with me from Visual Basic…

Window name convention : WinWindow1
Class name convention: ClsMyClassStuff
Label name convention: LblStuffForLabel
Groupbox name convention: GbxMyGroupboxStuff
… you can see the trend…

This way I can reference a window, label, or anything with the correct topic and I know that the window, class, or label is being referenced in the autolookup.

Just my $0.02 :slight_smile:


[quote=16901:@Eugene Dakin]Camel case with pre-abbreviations - kind-of stuck with me from Visual Basic…

Window name convention : WinWindow1
Class name convention: ClsMyClassStuff
Label name convention: LblStuffForLabel
Groupbox name convention: GbxMyGroupboxStuff
… you can see the trend…

I like this for the autocomplete benefits. I currently tack at the end a suffix because I group stuff by first name and categorize by suffix but I’m thinking this would provide more of an immediate benefit.

I use snake for controls and camel for variables.

Examples from the project in front of me:

dim dobValid as boolean

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)

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.

Yes indeed… Why not ‘p’? Why do I have to always change this ‘m’ to & ‘p’ because I’m using a convention that’s different?
It would be great to have a preference setting. I’ll file a feature request for that, after a due search, of course!

I use pBlahBlah for pointer values, typically from External method calls. mBlahBlah for member variables. Another reason not to use p to indicate Private is that p could be the prefix for Private, Protected or Public.

Because the property is a “member” of the class.

LOL! All this time and I never thought of it that way.

I really like discussions like this, it makes one think outside of their own box. New ways may be better, worse or no different, but thinking afresh is rarely a wasted effort.

My personal prefs: camelCase everywhere except SQL. Table names and fields are snake_cased. :slight_smile:

Same way here when it comes to Xojo, but I wonder, why? Why not CamelCase in SQL?

Old school here, and I am used to it. The prefix_more_names was the Oracle way few years ago. If I recall correctly, Microsoft teachs CamelCase for MSSQL. Nothing holds you from doing your way. But… some DB servers can be case sensitive about those symbols and I feel failing less writing “this_is_my_special_field” and reading after, rather than sometimes writing “thisIsMySpecialField”, and doing mistakes like “thisIsMySpecialfield” or “thisMySpecialField” in your code after. In your program, when you commit errors, your compiler will alert you, but not for your SQL part that is usually just “strings”. In a DB, someone could be working with those data live, so trying to be more clear from the start can be a good policy and renaming fields and tables in production is not a good thing. I saw a funny thing in the past, a funny table name with switched letters, the DBA told that he made a mistake creating the table and the DB entered in production and was being populated, so he let it that way… forever. :slight_smile: