As an Access programmer I am familiar with the Reddick VBA (RVBA) Naming and Coding Conventions and found them to be pretty helpful.
Is there anything similar for Clarion? As a newbie to Clarion I don’t want to develop the wrong habits 
See also http://www.xoc.net/standards/
or
1941APPA.PDF (405.9 KB)
The more sample code I read, the more I am noticing:
Local variable names are all in lower case
Variables passed as a parameter begin with p and then follow PascalCase
Clarion reserved words are ALL CAPS
PROCEDURE and CLASS names are in PascalCase
Hungarian notation is mosty not used 
Is this accurate?
I work as a consultant for a number of clients and see varying standards.
Some upper case all key and reserved words.
I personally, for my own work or where a standard isn’t specified by the client, have moved to all lower case for key and reserved words. CamelCase for variables , classes, procedures and method names.
I find it quicker to type.
No one that I know is using Hungarian notation.
The standard is whatever the boss wants.
I’ve personally moved toward ALL CAPS on Clarion words.
I also do the pParameterName
Sometimes I use ALL_CAPS_WITH_UNDERSCORE for equates.
I see a lot of other folks who do a lot of other things, and I doubt you’ll get a consensus on anything. I have changed a lot in my coding style over the years and I am sure it will evolve in whatever years Ieft doing this..
As others have said there’s no “standard” and even “conventions” are pretty loose.
The p in front of a parameter thing seems to be pretty common these days, and certainly makes code easier to read. Occasionally I use *r instead if the parameter is being used exclusively as a “return value”.
The upper/lower case thing is strictly to taste. I mostly code in lower case (it’s easier to read than upper case) but I also try and use Pascal Case as I think this is the easiest on the eye when reading. The IDE doesn’t support this though so inevitable my code ends up being a mix of lower case and pascal case.
I often use upper case when using custom equates in some specific code. I tend to use lower case for generic equates in classes though, and things like prop:whatever
When I’m writing classes I hate using PRIVATE or PROTECTED. So I tend to use a syntax of prefixing “internal” methods and properties with an underscore (_). This tends to indicate “override this at your own risk” and most often these methods and properties are not documented. Occasionally this leads to (cosmetic) issues as (for embedding reasons) it can be hard to change a method name when it becomes a popular embed point.
In the past I’ve used underscores in general variable and method names, but I mostly don’t do that now. I prefer camel case to underscores.
As always it’s not that there’s one true convention. The real goal should be to make your code as easy to read as possible, and consistency is the most useful aid to that.
Cheers
Bruce
I found this document by Jim Morgan and Fred Schmitthammer entitled “Clarion for Windows Development Standards” that has a lot of useful comments and ideas.