Tips/resources for structuring C code? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this qu开发者_C百科estion? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question

Does anyone have tips/resources for how to, in the best way, structure your C code projects? (Different folders etc.) And how do you know when it's good to split code into separate files? And what is an example of a good Makefile?

My project is not that big, but I wanna start to structure my code at an early stage..

---

Structuring code needs some experience but mostly common sense.

For splitting code, you usually go for readability: conceptually coherent functions/datatypes should go in the same file. You can take c standard library as a good example. It is better to keep your data structure definitions and function declarations in separate headers. This allows you to use the data structures as part of a compilation unit even if you have not defined all the functions.

Files that provide similar functionality should go in the same directory. It is good to avoid deep directory structure (1 level deep is best) as that complicates building the project unnecessarily.

I think Makefiles are OK for small projects, but become unwieldy for bigger ones. For really serious work (if you want to distribute your code, create an installer etc) you may want to look at cmake, scons, etc.

Have a look at the GNU coding standards: http://www.gnu.org/prep/standards/standards.html

Look at the gnu make manual for a simple example Makefile. You can also pick up any opensource project and look at the Makefile. Browsing code repositories in sourceforge.net may be useful.

---

Read one of the many C coding standards available on the internet and follow one that looks reasonable for your requirements. A few links:

• GNU Coding Standards
• C Coding Standards at IRAM (pdf)
• Indian Hill C Style and Coding Standards

The following books also contain effective guidelines on writing good C code:

• The C Programming Language
• The Practice of Programming
• The Elements of Programming Style

---

This is sometimes overlooked, but security is an issue in big projects. Here's some advice about how to program securely.

---

Here is an idiom I like:

Declare structs in a header so that their size is known by client code. Then declare init and deinit functions to the following convention:

• The first parameter is a struct foo*.
• The return type is a struct foo*.
• If they might fail, the last parameter is either int* (simplest), enum foo_error* (if there are several ways it can fail that the calling code might care about) or GError** (if you're writing GLib-style code).

foo_init() and foo_deinit() return NULL if the first parameter is NULL. They also return the first parameter.

Why do it this way? Calling code doesn't have to allocate heap space for the structure, it can go on the stack. If you are allocating it on the heap, though, the following works nicely:

struct foo* a_foo = foo_init(malloc(sizeof(*a_foo)));
if (a_foo == NULL) {
  /* Ruh-oh, allocation failure... */
}
free(foo_deinit(a_foo));

Everything works nicely even if a_foo == NULL when foo_deinit is called.