Hi, I need some hellp with my code structure.

Hi Cris,

The following rules extremely strong guidelines I think apply to your specific scenarios:

(1) For every .c file apart from main.c, create a header file with the same name. Otherwise, it's extremely confusing, and causes the types of issues that you are seeing. So, for lamps.c, there should also be a lamps.h; anything else is definitely unorthodox. The same name header file (with .c replaced with .h) is the standard way. If you feel that will result in too many files for your volume of code, then that's a sign that you may have too many source files, e.g. all lamp related functions may be better in a single file than several (this is just an example).

(2) For every header file, stick in there the function prototypes, that you want to be accessible elsewhere. So, your lamps.h file should contain void lampTest( int state ); and your lamps.c file should not contain this prototype.

(3) Each .c file should contain a #include with the same name header file. So, your lamps.c file should contain #include lamps.h

(4) Each header file should contain something like the following:

#ifndef __LAMPS_HEADER_FILE__
#define __LAMPS_HEADER_FILE__
/* the rest of the file */
#endif // __LAMPS_HEADER_FILE__

This too is standard, always to be done without question. If it isn't done, then it's again extremely unorthodox.

(5) Now you are free to liberally use #include "lamps.h" in any file you like. There's no issue with excessively using it, because the linker will only use it once, regardless of how many places it is included, so you're not bloating the firmware. For readability, sure it should only be used where needed. So, your main code will contain #include "lamps.h" and you will be free to use the lampTest function in the main function.

(6) Absolutely important (same level as feeding gremlins after midnight! this is defcon 1 level): Never define variables in your header files. Always in .c source files, otherwise again it's in unorthodox territory where it will sometimes work but will often cause issues. If you need to access that variable from a different file (for instance, if (say) you have a lampState variable defined in lamps.c that you also wish to use in main.c, then you must use an extern declaration, and ideally in the header file. So, your lamps.h file would contain extern int lampState; and then your main.c file needs to contain nothing except the #include "lamps.h".

There are plenty of other guidelines, but the ones above are most directly related to the types of symptoms you are seeing, and it's a guaranteed approach. The concepts are solid.

If you want to be sure that any of the above is normal, it's good to examine trusted code, for example peek at the Linux source code, e.g. this header file. You'll see examples of extern in there for instance, but you could browse other files from that link too, to follow how others coded it.

By the way, there may be "more standard" ways to do things (for instance, there are conventions on naming of things, which I have not followed above, since I'm not a C developer (any more). Also, there are more modern techniques, for instance, the C++ concept of setters and getters reduces the need to share variables across files, and such concepts can be coded in C too. But that's for another day.

Finally, if you upload your code to (say) replit, then others can inspect and optionally edit your code (if you give them permission : ). 

What shabaz  said ^  

It can be tempting to cut corners by skipping coding best practices, but then you often run into issues that cost you so much more time and frustration later.

Often times the boilerplate code is boring. Good news: you can ask ChatGpt to write your headers, then write a skeleton C implementation file as well. Can be recruited for other tasks, like writing functional code as well. 

It all pays off in the end.

I use a very similar structure to that suggested by Shabaz (although I've been told that I shouldn't use the double or single underline as a prefix to #defines in my application code).

One pay off is that I have been able to write a cloning programme which can refactor complete projects changing the root name of all the files and include file protectors etc.

so my files are all names:

project_description.c (or .h)

project will usually be something like alarm_clock, alclk  etc  - a project name abbreviation

description is an abbreviated description of the purpose of the file (module).

SO the source file folder for a project looks like:

The root file name for this project is dctrl

and it can be cloned like this:

The cloner is very Keil MDK specific and modifies the Keil IDE files as well as the source  files.

Every file gets an cloner generated internal header like this:

//
//       FILE: dctrl_project.h
//  COPYRIGHT: 2022 MK Electronics Ltd
//
//     AUTHOR: MK
//       DATE: 06/10/2022
//     ORIGIN: New
//
//    PROJECT: OLED and LCD Display Controller
//   HARDWARE: GD32E103C8
// TOOL CHAIN: KEIL
//

// Define to prevent recursive inclusion 

#ifndef DCTRL_PROJECT_H
#define DCTRL_PROJECT_H

It takes out some of the hassle of the boilerplate code.

MK

It all pays off in the end.

I use a very similar structure to that suggested by Shabaz (although I've been told that I shouldn't use the double or single underline as a prefix to #defines in my application code).

One pay off is that I have been able to write a cloning programme which can refactor complete projects changing the root name of all the files and include file protectors etc.

so my files are all names:

project_description.c (or .h)

project will usually be something like alarm_clock, alclk  etc  - a project name abbreviation

description is an abbreviated description of the purpose of the file (module).

SO the source file folder for a project looks like:

The root file name for this project is dctrl

and it can be cloned like this:

The cloner is very Keil MDK specific and modifies the Keil IDE files as well as the source  files.

Every file gets an cloner generated internal header like this:

//
//       FILE: dctrl_project.h
//  COPYRIGHT: 2022 MK Electronics Ltd
//
//     AUTHOR: MK
//       DATE: 06/10/2022
//     ORIGIN: New
//
//    PROJECT: OLED and LCD Display Controller
//   HARDWARE: GD32E103C8
// TOOL CHAIN: KEIL
//

// Define to prevent recursive inclusion 

#ifndef DCTRL_PROJECT_H
#define DCTRL_PROJECT_H

It takes out some of the hassle of the boilerplate code.

MK

Hi Michael,

Nice idea to have helper programs etc to set up projects!

I just saw this in GNU documentation, which confirms the definition naming convention that you mention. And finally discovered the name for it from that link; the whole #ifndef.. #ifdef thing is called a "Once-Only Header".

 michaelkellett using #_name should be NEVER used as this is RESERVED for the OS!  This will bite you in your ass!!

~~ CAH

 michaelkellett yes when I use Eclipse for C or Java I get  this

/*  Author C. A. Harrison
 *  Date: July 29, 2023
 *  Licence: (This depends on the project)
 *  Name: Landing Gear System
 *  REV: -
 *  IDE: Ecipse x.xx toolchain: GNU GCC
 *
 *  file: landingGear.c
*/ 

All I did was set it in my prefrenss. 

and normally my programs are set up in my REPO

something like this: (this is for NexGen-j)

public/NexGen-J/Aircraft/ Electrical
Engines
FireSystem
LandingSystem
      bin
      src
            Arduino
                   LandingSystem
                         LandingSystem.ino
                         isr1.c
                         isr2.c
                         isr3.c
                         isr4.c
                         isr5.c
                        lamps.c
                        include
                                    defs.h
                                    isr1.h
                                    isr2.h
                                    isr3.h
                                     isr4.h
                                     isr5.h
                                     lamps.h
                                     landingGear.h
             java
                   LandingSystem.java