C programming hints and code-style (part 1)
Over the years I’ve had to deal with many different coding styles (can something without style be called style?). Here is a list of no-brainer tips that every C programmer should be aware of.
Hints
Update:
Have a copy of the C99 spec handy
Don’t scratch your head when you are not sure if a function is part of the standard, and what is the expected behavior, open the spec an check by yourself: here.
free() can receive NULL
There’s no need to do:
if (pointer)
free(pointer);
This works fine:
free(pointer);
Therefore if you write a struc_free function it makes sense to allow NULL as an argument.
There’s no need to cast a void *
tmp = (EXTEREMELY_UGLY_TYPE *) malloc(10);
malloc() returns a void * there’s no need to cast those:
tmp = malloc(10);
sizeof can receive a variable
size = sizeof(EXTEREMELY_UGLY_TYPE);
No need to burden yourself with that:
size = sizeof(tmp);
If tmp is a pointer you can do sizeof(*tmp) and so on.
Avoid big macros
Have you seen horrendous code like this?
#define ERROR(e, code, text) \
G_STMT_START { \
if ((text)) \
GST_WARNING_OBJECT ((e), "error: %s", (text)); \
gst_element_message (GST_ELEMENT((e)), GST_MESSAGE_ERROR, \
GST_STREAM_ERROR, (code)); \
} G_STMT_END
It’s much cleaner to use an inline function:
static inline void send_error(GstElement *e, int code, const char *text)
{
if (text)
GST_WARNING_OBJECT(e, "error: %s", text);
gst_element_message(e, GST_MESSAGE_ERROR, GST_STREAM_ERROR, code);
}
Yes, you can put inline functions in header files.
C99 is your friend
C99 has nice types such as bool (true and false), uint32_t and similar int types. Also these beauties:
static struct device = {
.base = 0x480bd400,
.irq = 24,
.pdata = {
.name = "isp",
.nr_tlb_entries = 8,
.clk_name = "cam_ick",
},
};
I don’t even want to imagine how horrible the code would look for C89.
Those are the ones I can think about, any suggestions? On the next part I’ll about code-style 
I concur on hint 1.
Hint 2 and Hint 3 could lead to a little confusion. I.e.
MY_PRETTY_TYPE *my_var
[hunderds of lines]
my_var = malloc (sizeof (my_var));
I can not see directly which type and how big is my variable if I’m a novice. I like the hint either way.
I totally agree on hint 5
Daniel Charles
June 4, 2009 at 19:03
@charles it’s actually:
my_var = malloc(sizeof(*my_var));The beauty of it is that you don’t actually need to know the size of the variable, you just know that it will have the right size, I don’t see how that could be confusing.
This would be confusing:
my_var = malloc(sizeof(*my_other_var));But I’ve never seen such a thing.
FelipeC
June 7, 2009 at 11:03
Felipe, it would be good if you include reference. I don’t buy all of it.
elmarco
June 9, 2009 at 22:50
@elmarco Huh? Reference to what? In each point I’m showing two ways of doing the same thing, one which is ugly and the other is not (IMO), both work.
FelipeC
June 10, 2009 at 0:14
@felipec: who said that free can receive NULL to start with?
Marc-Andre Lureau
June 10, 2009 at 0:17
@elmarco The C99 standard in section 7.20.3.2 says:
The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action occurs.
FelipeC
June 10, 2009 at 0:58
felipec: well, that’s the kind of things that you should mention, otherwise it’s not useful. Also, C89 is still what most people use. From http://en.wikipedia.org/wiki/ANSI_C, you can see they (who, I wonder?) that msvc is not c99 compliant…
Marc-Andre Lureau
June 10, 2009 at 1:06
It’s also part of C89.
If somebody doesn’t believe my proposed alternatives are C compliant they can check the standard themselves and figure out. I’ve updated the post with another tip: have the spec always at hand
Also, all of the hints in this post are used in the Linux kernel and I think they know how to use C properly
FelipeC
June 10, 2009 at 1:27
A teacher at college always said: “A hint is provided for help you find the solution of the problem, you can choose to use it or not”. I still find them very useful
Daniel Charles
June 11, 2009 at 1:48