Does anyone follow a set coding standard for Xojo?
The reason I ask is that I am trying to get a contract and part of their immense paperwork is that all programming follow a published coding standard.
There are some publicly available for Python, Java, C++, etc., but I was wondering if one existed that was general enough to apply to Xojo as well.
If you search my blog (www.bkeeneybriefs.com), I’ve done a number of posts about Xojo coding standards. I don’t think it would take long to come up with a document of standards you can live with.
I threw together a Coding Guidelines document based on what I use. Feel free to disagree with it, modify it and even argue amongst yourselves about it. But just remember, my way is the right way!
thanks so much!
I pretty much do a lot of what Paul does except the suffix are prefix for me
txtTextFieldName
lblLabelName
winWindowName
etc
Reasoning is that the Navigator orders the controls by control type and autocomplete works better (IMHO). If I want to work with a textfield but can’t quite remember the control name I just type txt and autocomplete shows me all the textfields - handy dandy!
Each to their own - but Paul’s is the right way of course! 
Hi Patrick, i do the same as you for controls and windows. I do the prefix instead of suffix.
my coding standard(s) (would love to say I only have one but we all know about reality) has the type as the prefix for variables, controls and such. windows and menubars I have Window and Menubar. which is my only exception to the prefix.
So maybe Paul is wrong then!
I have thought about prefixing variables with type but that’s a step too far for me…
[quote=241355:@Patrick Delaney]I pretty much do a lot of what Paul does except the suffix are prefix for me
txtTextFieldName
lblLabelName
winWindowName
etc
Reasoning is that the Navigator orders the controls by control type and autocomplete works better (IMHO). If I want to work with a textfield but can’t quite remember the control name I just type txt and autocomplete shows me all the textfields - handy dandy!
Each to their own - but Paul’s is the right way of course! ;)[/quote]
So much this.
i have to for quick debuging. if I see strName with a number in it, then I know that there is a problem. strName is the “name” field/property/item that is of type string.
but I could be wrong. I am wrong many times a day, every day. just trying to be right more than I am wrong.
[quote=241369:@scott boss]i have to for quick debuging. if I see strName with a number in it, then I know that there is a problem. strName is the “name” field/property/item that is of type string.
but I could be wrong. I am wrong many times a day, every day. just trying to be right more than I am wrong.[/quote]
It’s whatever works. Consistency is the important thing, pick something and go with it…
Your not wrong - Paul is…
nobody is “right”, and nobody is “wrong”… but I agree “Consistency” is most important.
I have my ways… and the only time I change them is if an employer has a specified manner they require.
Just sarcasm…
Unless your Paul - then your wrong…
For us, an instance of the a class starts with an o. So an instance of class Person would oPerson. For some that’s probably a horrible convention but I find it easier than coming up with some intermediate name. It means something obvious and tells me what type it is. If I’m creating a new instance I will often call it oNewPerson as new Person.
For arrays we always prefix them with ar. So an array of Person would become aroPerson(). Again, tells me its part of an array and that it’s an instance of the Person class.
The bigger the method local variable names mean something. If you have to scroll up to figure out what it is then you need to come up with a better name. I’m working on a project right now where 500 line methods have tf as boolean and it’s used several times and has different meanings depending on where it’s used. Drives me nuts because it doesn’t tell me anything (though I know it’s a boolean) on how it’s used.
In the long run, it doesn’t matter that which way is ‘better’. What really matters is sticking to whatever convention you come up with. You are not doing this for right now, six days from now, but really six months or years from now when you have to back and edit this code. Your coding conventions should make your life easier - not harder.
All of my life, I had used the Hungarian notation. (strName as string, intID as integer, etc.)
It wasn’t until recently that I learned it is old-fashioned. I’m trying to become more modern, but I’m finding I end up mixing and matching which is worse.
As long as there is some kind of standard in place, I’ll adapt to whatever it is.
But I agree 100% with Dave. Consistency is most important.
If there is no standard or it’s one of my own projects, I pretty much do the same thing as Paul but a little more.
I prefix controls etc:
txtTextField
cvsCanvas
btnButton
lblLabel
frmWindow (I think ‘frm’ came from Delphi with it’s Forms)
etc.
If there are (for example) two labels where the first one is fixed and the second changes like:
Username: John Smith
Then the first label is called:
lblUserNameTxt
and the second
lblUserName
I prefix standard properties like:
iInteger
bBool
dDouble
sString
And the rest with and ‘o’:
oPicture
oClass
oDictionary
oSomethingElse
Local variables and function/method parameters camelCase (with a descriptive name but no prefix).
I shadow subclass properties I’ve added to the inspector with my initials:
mhText
mhCaption
mhColor
I comment everything everywhere and use //:
// This is a
// comment block
ElseIf // Comment
And lastly global methods/functions in TitleCase and private/protected methods in camelCase.
That way, I don’t have to think and see immediately what it is. I do this since forever if whatever language I use allows me to.
I often see code from others where they write things like:
drawnow2 1,2,3,true
Instead of
drawCanvasImage(2, 1, 2, 3, True)
I think the second is more clear.
And in Xojo, I always use Jeremy’s Format Code script: https://github.com/jcowgar/xojo-format-code
I love that thingy.
I have a bad habit of using Len(int) instead of int.Len, Str(int) instead of int.ToText etc.
I guess I need to work on that.
The ultimate test is : pick up code from some years ago. If you feel home, your coding style is valid. Whatever it is.
I tend to use long and descriptive variables and method names, and some comments that explain what it does more than what it is. Also, I tend to prefer verbose and explicit code than the most compact.
To me, the structure If then else end if is far more explicit than if (condition, "one thing", "another thing"). While coding, when one’s mind is deeply into the logic of the program, compacity feels right. But three years later, It can become too cryptic for my taste.
The ultimate test was when in 2013 I fetched Barcode Wizard that I had written back in 2002 to put it into the MAS. Not only Xojo very gracefully opened a project that had been saved by RB 5.x or some like that, but I was able to read my own code and feel right at home.
Wouldn’t they be referring to their own published standard? Not some foreign standard from internet-land?
Unfortunately for the rest of you, my standards are now published and will soon by adopted by everyone! 
I understand why you’d use a prefix for control types, but I find them hard to read so I stick with a suffix. I’ve always found I spend much more time reading code than writing it.
Regardless, consistency is what matters.
Paul, I checked your standards thoroughly and have determined they are incorrect. My standards are top secret so I cannot release them to the public. Also, I dont spend much time reading code. I just write it quickly and it always works the first time.