Where do you place your Variable Dims?

[TimB]

Ok as you will have realised I'm not a particularly good coder. I suffer from the Dunning-Kruger effect. I think I can do something then try and ages later I realise I'm rubbish at it but in the interim I actually did progress a little so carry on. I spend a lot of time scratching my head...

Any way back to my question. Where do you place your variables in your code? I used to place them all at the top of the program. Occasionally I would try and organise them but after a while it gets a mess.
As I'm trying to reuse code more and more and with Procs I honestly thought about includes but since so much code has to be tailored to the device I gave up on that idea. I prefer the idea of just cutting blocks of code from other programs and pasting them inline.

The issue as you will imagine is that all them vars used outside the Procs its a pain finding them and doing the same thing next time I need that routine.

Now I'm trying to just make blocks of relevant code. I generally start with an Initialisation proc then the main routines. I also include all the vars used that communicate the data that cannot be passed back in a block of vars just above the main routines. Underneath the compiler may be screaming at me for doing it but it works.

Now I'm I doing it wrong? Should I force myself to make standalone Includes? What do you do?

[John Drew]

Hi Tim,
I always place them at the top, along with symbols in every main file I write.
This means I always know where to look. Equally you could always put them at the bottom. As long as it's consistent.
I don't like scattering them about.
The compiler doesn't care.

I use Includes whether they are true libraries or not as it keeps files specific to a set of related routines together and it keeps all files fairly small with a name that describes their purpose.
John

[flosigud]

I used to place all my dims at the top. Then we got procs with both local and global variables, so now I of ten use that. Highly convenient in libraries to have an init routine with all setup.

[keytapper]

I'm, for one,  using mostly 8 bit MCUs, midrange family, so some times is important where the variables reside. To avoid them to be splitted across banks,  i order them whit their size order,  bigger first. Some time I check the compilation results.
Maybe the 16 bit MCUs also need to align the variables to even address. Then Arrays, Dword, Word are first on the listing.

[Stephen Moss]

I generally put them all my Constant/Alias/Variable definitions at the top of main .BAS file following the typical layout in the Positron manual and because in VB I create a Module for all my Global Variables but by the nature of VB local variables are located in the individual procedures.

But now that Positron has procedures I am staring to mix up more with Globals at the top and locals in the Procs and getting better at passing locals from one Proc to another as required, although there are times where defining something as a global is still more coinvent.

The advantage of defining then locally in Proc is that it should not matter if you reuse the same variable name to make it readable as internal they should be assigned different names, whereas if you are not using locals in Proc or Includes it can make sense to group them all the top of the main file making them all global to help stop you trying to use the same name more than once as you can then easily find and check whether you have already used a particular name.     

[Gamboa]

Hi,

Starting from the fact that I am not a professional programmer and my studies have always had to do with electronics, I am going to contribute my experience. In the last work that I have done I have used Includes for the constants and for the aliases of the pins. I put the variables at the beginning of the .BAS file.

I also use variables in library includes. I usually name these variables with a prefix common to that library. For example, if it is a library that is from RTC, then all the variables used in that library are named as RTC_Tempo, RTC_Counter, etc.

Regards,
Gamboa

[TimB]

Hi all responses very appreciated

keytapper
I used to place my vars at the top and try and arrange them all in sections due to banking but these days do not care, Positron handles all that. No longer do I get the "variable is crossing a boundary" message

[RGV250]

Hi,
If I have a lot if include files I have started placing the variables that are used specifically (or mainly) at the top of each include file. So far it has worked and makes the main BAS file less cluttered which is why I use the inc files in the first place,

Bob

[JonW]

I am trying to use libraries procs for most code now.  I recode the SPI, I2C, ADC reads with quantistion, flash read and write libraries, and device specific libraries that use other more basic libraries etc.  I use variables within  the procs for loops and tend to avoid global temporary vars as this can easily cause variable corruption and waste a bucket load of time.  If the library has multiple procs with loops then will use  global vars but place these in the include file like Bob does then there is no variables to be included in the main program.

My main programs are really short  and will always place variables and symbols at the top and separate the uses.  I then work on new procs within the  main code and finally produce an include and remove them from the main code file into an include and copy any global vars to the Inc file.

I am now starting to use the PINxx functions so I only have declares in the main code.  I also split out the chip setup into an includes so the main code flow can be reused easily by changing the include files at the start of the code.

I always document the Library well and have a conmented out example of the the proc calls in either the include file itself or in a massive PPT that I keep for catalogging all of libraries. Put a header page in the PPT with a description and hyperlinks to the library sections. This way if its reused later its easy to get up and running.

[RGV250]

Hi,
The only thing I forgot to mention is that if the variable is used in other routines you have to think a little about the order of the INC files in the main program.
As JONW says, it makes the main file very small, in my opinion this makes it much easier to follow.

Bob

[top204]

The RAM bank splitting will always occur with 8-bit PIC microcontrollers when different variable types are used, and the compiler handles them well. However, I added a declare in the Positron8 compiler a few versions ago to stop that happening and making the code more efficient and faster to operate:

Declare Auto_Variable_Bank_Cross = On  ' Make sure all multi-byte variables remain within a single RAM bank (for faster code operation)

See page 418 of the compiler's manual: "Variable Declares"

It does have a very, very small issue, in that it will produce some dummy byte variables to fill the 2 or 3 byte gap between the RAM banks if a multi-byte variable type is approaching it and will be split between them. But these are very small amounts of RAM that can sometimes be required and the benefits are much greater to the program's operation. Other compiler's also fill the gaps between RAM banks on the 8-bit PIC devices because most of them cannot handle variables that cross them, but Positon8 can. :-)

[keytapper]

keytapper
Positron handles all that.

I learned my way that's possible to let the compiler handle the bank swap, but there's a price to pay. That's rather proibitive in small MCU.