Hi, I need some hellp with my code structure.

 ggabe  sorry but this is a sign of a lazy mind. 

 shabaz  yess. I agree with most. but 4 is well a toss-up.  in a large production codebase, I agree because I use it for debugging.  ifndef -endif is very good where you have two or versions in the same package. you just the define the on you wish to use. But this is not the case!  So I decided not to use that "structure"

Nope, Nada, Old wifes tail. #6 First its a great place to store all of your vars, defs , structs, etc. You just should not put active code segments there here are few that break that rule too:

definition of PI, and we don't have one. so we can get lazy by doing something like this: const int PI = 3.14 ( but it needs 16 decimals there). now question why the const its not needed. It just tells the compiler that wait you can't change this value, and I normally don't use it. you could  use atan2() a math function. like this: const double pi = atan2(1,1) but why?  #define PI atan2(1,1) and let the compiler figure it out. and btw once it is defined you can not change the value. 

and I have one more for you how about the square of a number, nope C does not have one either. to square a number you have to multiply it by itself. so you could end up here. square( n )  but wait you need to declare what type is n. so that's not going to work again here is the solution #define SQ (a)*(a)  but we can change the SQ to something more useable. what about the @ symbol? or ƒ the symbol so  A² + B² = C²would become A² + B² = C². Aƒ  + Bƒ = Cƒ   I kinda ike it. So the #define is this: 
#define  ƒ (n)*(n) and there is no rule agaist it. beauty rains.

~~CAH

I thought lazy is the new good: https://www.forbes.com/sites/forbestechcouncil/2018/01/08/developers-are-lazy-and-thats-usually-a-good-thing

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

~~ CAH

Agree, the worst thing that can happen to a software development team is that a hard-working fool joins the team. A developer has to always be thinking about automating everything possible and working as little as possible. And keep it simple is the motto to follow.

 ggabe yes I agree with Forbes.  but then you get stale and don't grow. 

 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

Hi Cris,

This is what's causing the problems, because there will be corner-cases (sometimes more often than not) where things will break down and not compile (as you have seen) unless those guidelines are followed. There's not going to be a single place in the entire Linux source code which includes variables inside the header file.

As further corroboration: I don't have any old C books at hand, but if you're willing to accept the writings of Bjarne Stroustrup (a C++ guru, he has many computing-specific awards as a result of his career), this is what he wrote regarding topic #6. You can see in red he explicitly calls out variable definitions (by variable definition I mean literally the example I gave, int lampState. Consts and externs are fine; but that's not part of what is forbidden in guideline #6. 

Similarly with topic #4. Again, this is what Stroustrup wrote:

 (photos are from The C++ Programming Language by Bjarne Stroustrup).

It is fine to deviate away from convention, but that's a more advanced thing. The whole purpose of good guidelines/rules is to help prevent getting into trouble later. You can see that Stroustrup mentions the #ifndef/#ifdef thing works (and that's a guarantee, there's no condition on it).

That's why I say these are rock-solid guidelines. One can bend the rules and still achieve successful compilation and operation eventually, but these techniques mentioned above work 100%.

I’ve always considered header files to be like the index cards in a library card catalogue - it tells you what’s in the actual books, but you’d never put a book directly into the card catalogue drawers.

Basically, header files give references to things that are available in the .c files.

I have to agree with shabaz - stay away from having anything “real” in the header files and you’ll be far less likely to run into the issues you are asking about.

This is why I really don't care for C++ as you see most of what I write is in C not C++  where things that work don't.  case pinpoint  I have a valid typedeft struct which is initialized when I defined it: (landingGear.h) 

typedef struct lamps{
      char name[15];
      char color[10];
       int pin;
}Lamps[10] = {
{"RIGHT", "RED", 22}, {"NOSE", "RED", 23}, {"LEFT", "RED", 24},
{"RIGHT", "GREEN", 25}, {"NOSE", "GREEN", 26}, {"LEFT", "GREEN", 27},
{"WARNnose", "GREEN", 28}, {"WARNgear", "ORANGE", 29}, {"WARNnoseDis", "BLUE", 30}, {"WARNskid", "RED", 31}};

now i have used this type of code for a long time and I works.

and I include it in (lamps.h)

#include "include/landingGear.h"

void lampTest( int state );
void lamp( Lamps.pin[count], int state );
void blink( Lamps.pin[count] );

and again in lamps.c

#include "include/landingGear.h"
#include "include/lamps.h"

void lampTest( int state ){
for( int count = 0; count < 10; count++) {
digitalWrite( Lamps.pin[count] ); }
}

void lamp( Lamps.pin[count], int state ){
digitalWrite( Lamps.pin[count] );
}

void blink( Lamps.pin[count] ){
//TBD
};

and I get this crap: 

In file included from sketch/lamps.c:2:0:
landingGear.h:8:1: error: unknown type name ‘lamps’
lamps Lamps[] = {
^
In file included from sketch/include/lamps.h:1:0,
from sketch/lamps.c:3:
landingGear.h:7:1: error: conflicting types for ‘lamps’
lamps;
^
In file included from sketch/lamps.c:2:0:
sketch/include/landingGear.h:7:1: note: previous declaration of ‘lamps’ was here
lamps;
^
In file included from sketch/include/lamps.h:1:0,
from sketch/lamps.c:3:
landingGear.h:8:1: error: unknown type name ‘lamps’
lamps Lamps[] = {
^
landingGear.h:8:7: error: redefinition of ‘Lamps’
lamps Lamps[] = {
^
In file included from sketch/lamps.c:2:0:
sketch/include/landingGear.h:8:7: note: previous definition of ‘Lamps’ was here
lamps Lamps[] = {
^
In file included from sketch/lamps.c:3:0:
lamps.h:4:17: error: expected ‘)’ before ‘.’ token
void lamp( Lamps.pin[count], int state );
^
lamps.h:5:18: error: expected ‘)’ before ‘.’ token
void blink( Lamps.pin[count] );
^
sketch/lamps.c: In function ‘lampTest’:
lamps.c:7:22: error: request for member ‘pin’ in something not a structure or union
digitalWrite( Lamps.pin[count] ); }
^
sketch/lamps.c: At top level:
lamps.c:10:17: error: expected ‘)’ before ‘.’ token
void lamp( Lamps.pin[count], int state ){
^
lamps.c:14:18: error: expected ‘)’ before ‘.’ token
void blink( Lamps.pin[count] ){
^
exit status 1
unknown type name ‘lamps’

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.