standard structure for C header and source files

Answer 1

The structure you are using is good.

Best practice is with regards to naming the public variables and public methods, prefix the same with the product's name / company's name to avoid naming conflict with other libraries.

Answer 2

Given that this is a C question, I presume:

// static variables
// public variables
// static methods
// public methods

... means:

// static variables
// public variables (external linkage)
// static functions
// public functions

As for the order, I don't think you can evoke anything but a subjective response about this. It is certainly not standardized unless you are asking about a specific organization's coding standards, in which case they might have policies about this. Some might prefer privates before publics, others publics before privates. Some might put one before the other to emphasize the importance of one over the other, while others might put it after to emphasize the important over its predecessor. There's no unanimous agreement about these kinds of stylistic preferences and they have no logical effect on the code or its runtime behavior.

The important thing is to be consistent and I'd recommend avoiding anything very exotic as it will scare away other developers who have to look at your code. Exotic styles are usually bad if you want to work with other engineers. The more exotic styles become, the more uniquely personal they are the more they demand of others to adjust to personal preferences.

Do try to cut down on the number of public variables with external linkage (global variables). As small a difference as it sounds, it's a big step up to write a public function to fetch a variable, even if it's simple getter-type function which returns a pointer to the variable, as it'll at least allow you to modify that code if a change ever becomes necessary and also allow you to easily put breakpoints wherever it is accessed, add instrumentation to the function, etc.

Answer 3

This is a totally subjective question. However, here's what I do approximately.

Header:

// extern defines, constants and enums
// public types
// extern methods

There are no extern variables :-)

Compilation unit:

// includes
// definitions for extern constants
// static function prototypes
// everything else

I tend to group things that are related together, so I don't rigidly put all of the static variables or defines in oner place, but near where they are going to be used.

Answer 4

I usually use the following for c:

// include guard
#ifndef <filename>_H
#define <filename>_H

// define this as extern for c++
#ifdef __cplusplus
extern "C" {
#endif

#include <libraries>
#define  <preproc variables>
#define  <preproc macros>

enum <enums> {
};

typedef <variables>;
typedef <structs>;

function prototypes();

// end c++ guard
#ifdef __cplusplus
}
#endif 
// end include guard
#endif