3

Some questions regarding efficient coding style using C:

I'm working on 8-bit PIC controllers using C. I would like to know certain things about coding style and structure.

  1. I have read that keeping one header file is good programming style. But for segmenting functions rather easily for debugging and future development, can we keep more than 2 header files? Or, is it error prone? I trust creating header files and declaring function prototypes will remove the extern declaration in each related source files by doing so. (i.e. eeprom.h, data.h)

  2. Is it a good practice to keep all variables in a separate header file? Also, how do you deal with variables that are needed in more than one source file?

Adam Lawrence
  • 32,921
  • 3
  • 58
  • 110
Rookie91
  • 2,108
  • 4
  • 29
  • 46
  • 1
    I cleaned this question up as best I could. I hope that I didn't alter the intentions of it, as the English was challenging. – Adam Lawrence Jan 30 '14 at 04:03

2 Answers2

2

Regarding question 2: Variables are not supposed to be defined in a .h file. The purpose of a header file is to declare "public" functions and data structure used in a C file, so other C files know how to call/use them. By definition a header file will be included several times in a whole project, That's why .h files should not contain any code, or this code will be duplicated (actually, most of the time this causes a compilation error). The only case when a variable should be declared in a .h file is global variable shared across several C files, in that case the variable is defined in one of the C file and declared as extern in the .h file.

About global variables: The actual reason why global variables are not so good, is because it prevents code using it from being re-entrant. That means the code wont be compatible with recursivity nor multi-threading. On a 8 bit PIC with a ridiculously small stack, none of those techniques makes sense, so global variables are not so bad. It is however common practice to avoid global variables when you can, code is easier to read/debug/re-use that way.

martinm
  • 664
  • 4
  • 9
1

Programming style depends on Individual and on which coding standards you are following.

I prefer modular header files. Every module, say EEPROM, will have EEPROM.h and even if EEPROM module is spread accross files, I try to use a single header file. It becomes difficult though but I try. Also, only public functions are declared in Header file while private would be in C file only. This helps in modularity of code.

There is nothing like having multiple header files becomes error prone. But yes, it sometimes become cumbursome to trace a function if there are multiple headers for one module.

About your 2nd question,

Good practise is you should not have global variables :-) Try to keep this count as minimum as you can. And having all variables in one file makes it risky in a way that your all variables are accessible to all files in your application. So, Doing extern is better than keeping all in one header file.

If you don't have memory constrains, Make Get() and Set() functions i.e. Make functions to read the value of a variable and set Value to that variable. By this, you don't need to make those variables extern or include in Header file. You can also make them inline to avoid jumping.

Do read this thread about Global Variables.

Community
  • 1
Swanand
  • 3,245
  • 5
  • 28
  • 45
  • 2
    I disagree with your item #2, specifically since the author is speaking about embedded platforms - specifically 8-bit PICs - which are very resource constrained - you simply cannot object-orient your code as you've described when you only have a few hundred bytes of RAM available. – Adam Lawrence Jan 30 '14 at 04:10
  • @Madmanguruman Point noted and edited the answer. I missed that "8-bit PIC" line but it is better to use partially object-oriented code to make it easy to understand and easy to modify. I will prefer this approach on ARM based controllers. – Swanand Jan 30 '14 at 04:18
  • Fair enough. ARMs are hardly resource constrained. – Adam Lawrence Jan 30 '14 at 11:35
  • I used a similar object-oriented approach on 8-bit PIC's (primarily PIC18's, to be fair) for many years. It's a very effective defensive programming mechanism, and is both easier to read and far safer than filling code with extern statements to access variables. For my money, any use of extern statements for anything other than debugging indicates lazy coding, and lazy code is generally untrustworthy code. – markt Jan 31 '14 at 00:37