News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

Format for variable names

Started by See_Mos, Aug 01, 2021, 11:18 AM

Previous topic - Next topic

See_Mos

I have some code of a few hundred lines to tidy up.  Some lines have been copied from several places and the format varies. Most of it is my own from both old and new code and even the formatting of that varies so I was wondering what is your preference?

ALLCAPITALS
MixedCase
lowercase
with_underscore
Etc.

I tripped myself up by having the same variable name for global and within a procedure and it took hours to find why the code gave random results so I will now prefix global with g and local with p.

I looked at adding the variable type as well but Bit and Byte would both be b

Dompie

I use an x for the bit variable and b for the byte. Works excellent for me.

Johan

TimB



I use

wMyword
swMysignedword
dMyword
sdMysigneddword
bMybyte
aMyarray
bfMybitFlag



John Drew

I also follow a scheme like Tim's but I see the value of Dompie's "x" for bits.
Re capitals, if you want legibility don't use full capitalisation for two reasons.
1) our brains use the height of letters as part of our recognition of words. Capitalisation loses this.
2) using mixed case allows for a simple phrase.
For example wDataIn is more easily recognised than WDATAIN.
John
An old chalky

top204

The same variable name can be used within a procedure and as a global and they remain different variables, unless the variable is made System or Access.

A local variable has the procedure's name added to it. So with the procedure:

Proc MyProc()
  Dim bTemp As Byte
EndProc


The bTemp variable is actually named MyProcbTemp.

If you press the F2 button, you will see the actual variable names used within the assembler listing.

I started using the preceding lower case characters for variable types many years ago, and I am so glad to see others using them now as well, because it makes code so much easier to understand and follow. Especially if a user gives a code snippet but forgets the give the variable declarations. So a variable named "wTemp" can be seen as a Word type etc...

My preference for bit variables is a preceding "t", because the technical name for a bit is a "Tetra", and a byte variable is actually an "Octet". i.e. 8 tetras. :-)

My preferences are:

't' for Bit
'b' for Unsigned Byte
'sb' for Signed Byte
'w' for Unsigned Word
'sw' for Signed Word
'l' For Unsigned Long
'd' For Unsigned Dword
'sd' for Signed Dword
'f' for 32-bit Float
'q' for a 64-bit Float
's' for a String

It is such a simple principle, and after a time using the method it becomes second nature to add the preceding character/s. It makes the code so much easier to follow and optimise, because you can see sections that will not require a larger variable type and see what variable type is being used in it, and vice-versa.


Tenaja

Quote from: TimB on Aug 01, 2021, 12:15 PMI use

wMyword
swMysignedword
dMyword
sdMysigneddword
bMybyte
aMyarray
bfMybitFlag
I do something similar, but I'm more active with mixed case. I.e. Tim's
sdMysigneddword
Would be my
sdMySignedDword
(Assuming the words in the name are not actually the var sizes.)

See_Mos

Some interesting ideas there.  I like xname or tname for BIT and t is the last letter of BIT.

The code I have been working on had index as a global variable and also index as a local variable in a procedure.  When I renamed the procedural one the erratic behavior disappeared but there is probably something other than using the same name that caused the problem and I am too far forward to try and reproduce it.