Let me prefix this by reminding you that I'm a hardware design engineer by trade -- I'm embarrassed to show my software. Suppose I have a "box" that contains three distinct areas of electronics: a chain of 7-segment display modules, an array of tri-colored LEDs, and an array of switches. These functions are independent of each other -- it's only a top-level program that will use them in conjunction with each other.

I've created programs to test all three for these functions in isolation -- now it's time to bring them all together. If you were creating the code yourself, which of the following two scenarios would you use?

SCENARIO A

All the #definitions in a bunch

All the global variables in a bunch

All the pin assignments in a bunch

etc.

SCENARIO B

All #definitions, global variables, and pin assignments associated with the 7-segment displays

Then all #definitions, global variables, and pin assignments associated with the LED array

Then all #definitions, global variables, and pin assignments associated with the switches

Kindest regards -- Max

Hi Max,

   I would opt for the second scenario, as it keeps the parts separate. This is useful when you need to reuse only a part, as well as when you want to focus on a single part (e.g., for debugging or maintenance).

    For the same reason, global variables are better avoided, unless your micro resources are very constrained; setters and getters provide a better and safer interface to global state.

    Also consider passing the pin assignments from the application to the drivers, so that your driver code can be reused with different pinouts.

    All the best

--

Max

Thanks Max -- that's the way I was leaning -- it's just that I've historically always put all my #defines at the top of my code -- so dividing them up seems a bit strange to me :-)

Kindest regards -- Max

SCENARIO C

Global Variables in a separate file so you know they are globals (sometimes it is just plain simpler to break rules and use a global).

I like to keep pin assignments in a single file so I can manage the hardware layer to the software layer without hunting down all the places the software think it should be doing something on the pins.

#defines are another matter... those should go with whatever it relates to. Usually in a .h file but if those only apply to local scope, they go in the top of the code.

Which brings me to related topic: how much code in a file: These days people like to put vast amounts of code in single file for some reason.  In the old days, the rule was that if it didn't fit on a single page (they were printed, probably on green bar), you need to break it all up and put it in several different files.  This of course in the day when all of Unix kernal was about1" of printouts.

KISS is the rule.

Thanks Randy -- This is a relatively simple Arduino program (it's for a retro games console project I'm creating as a series of columns for Practical Electronics magazine in the UK), so it will all end up in one file -- but I do sort of like the idea of keeping the pin definitions all together -- and then have three blocks, each containing #defines, type definitions, and global variables associated with that particular part of the console.

Kindest regards -- Max

Thanks Randy -- this is a relatively simple Arduino program for a retro games console I'm building and documenting in a series of columns for Practical Electronics magazine in the UK.

I do like the idea of keeping all the pin definitions together. But then having three "blocks" -- one for each of the main console functions (switches, displays, LED array) -- each having its own #defines, types/structures, and global variables.

Kindest regards -- Max