Code Style When Interfacing With Libraries (C)

Question

Recently I ran into a bit of an interesting problem in terms of coding style. Realizing that consistency is a key attribute of good code style, I inherited some code that had some interesting style patterns.

The code in question basically ties two libraries together. The program itself isn't too large. Code for utility functions that wrap the first library are found in a .h and .c file that total a whopping 100 lines (for both files). Code that interfaces with the second library is found in a .c file that also contains the main (total of 300 lines for this sole .c file). All functions that are written with the second library are made static since they are super custom to the particular implementation.

The problem I have is that each file has it's own style. The programmer in question has a style of his own, but the first set of files follows the style of the first library. The second file uses the style of second library. As a result, code in each file is locally consistent in terms of style, but the program itself spans several codes styles.

Style differences include using GLib types and functions like g_printf() in the second file and using C types and functions in the first set of files. In the second file (the one that interfaces with a library that uses GLib), there are portions that absolutely require use of GLib and others that do not. However, in order to maintain local consistency, the programmer used GLib throughout the file.

As a result, I'm wondering what the best practice is in this case in terms of code style. Here are the possible options as I see them.

1. Use the style from the first library in the first set of files and the style from the second library in the second set of files. This allows code from the library to match in terms of style and allows each set of files to be 100% consistent in terms of style locally, but not for the project as a whole.

2. Write the code with your own style, ignoring the style of the two libraries. GLib calls will be limited to where they are absolutely necessary. Standard C libraries will be utilized elsewhere. This will cause the code to locally not match styles between each file and their associated library calls. However, the code from file to file should appear somewhat consistent.

3. Pick one library's style to go with. While this should cause the project's code to be consistent, the code from this project to the programmer's other projec's will be inconsistent. Also, the source code file that has to follow the other library's style may look a bit off.

Looking forward to hearing any thoughts on this. I think this is the first time I've encountered a project's code shifting from one style to another with the same programmer. Thanks for your input and feedback.

Answer 1

• In my opinion use the coding style of your company (If you are coding for company).It will help many other in future.
• In case you have two different style maintain the coding style present there .
• If it is necessary then change the style of coding in the library file.

Answer 2

I see two different problems:

• Coding style
• Dependency on glib

For what concerns the coding style, it should be uniform across the project. Choose the coding style and rules that you prefer (from the first file, from the second, or one of your choice). But make it consistent across the whole project. That will require some effort, of course, but it will pay you off in future.

Dependency on glib should be isolated as much as possible, in order to let you switch this library in future. In C++ you usually create a dependency on an abstract class, which is then inherited by a concrete class ("Program to an interface (i.e., an abstract class), not to an implementation (i.e., concrete class)". Since you are in C, and you don't have classes, try to mimic this behavior by decoupling the code.