Tag Info

Hot answers tagged

12

It depends on what code is in the include file. Did you try putting the #include for <stdio.h> inside main()? Depending on how the standard library is implemented on your system it may not even compile. Header files can contain not only function declarations, but function definitions. Standard C doesn't support nested functions. If your header file ...


11

C programmers, on the whole, will expect the #include directives to be at the beginning of the file. Why risk confusing them without any significant benefit?


10

If a header file such as file.h depends on other headers such as stdio.h, then file.h should #include those headers as necessary. Each header file should keep track of its own dependencies, and use #include guards to prevent multiple translation if it winds up being included several times: #ifndef FILE_H #define FILE_H #include <stdio.h> ... void ...


5

To avoid ambiguity, you should always add the trailing slash. Not all files have extensions, so if you use this consistently in your codebase, you (and others) will be able to tell whether a path references a directory or a file at a glance.


5

Consider the possible things that may be found in a header file. Preprocessor macros. These will be available from the #include until the end of the .c file that includes the header. Preprocessor macros are not concerned about C block scope (braces), so even though the header is inside a function, the macros will still be available after the end of the ...


4

This is one of those "should" rather than "shall" kinds of coding standards. The reason is that you would pretty much have to write a C++ parser to enforce it. A very common rule for header files is that they must stand by themselves. A header file must not require that some other header files be #included before including the header in question. This is a ...


3

Its really very very bad! The reason is that many C header files include lot of macro stuff like:-- #if !defined(MYSTUFF_INCLUDED) /* File not yet included? */ #define MYSTUFF_INCLUDED /* Show file now included */ int variable1; int variable2; #endif macro variables have a "file" scope whereas any variables defined ...


2

If you need to enforce a rule that particular header files must stand on their own you can use the tools you already have. Create a basic makefile that compiles each header file individually but doesn't generate an object file. You will be able to specify which mode to compile the header file in (C or C++ mode) and verify that it can stand on it's own. You ...


2

I would refrain from changing vendors the headers, and work around limitations unless the workaround is being used too many times (more than once?). I now apply the following a guides. In most cases its presumptuous to think I know better than the vendor. (he says with only a slight hint of sarcasm) Upgrading the tool chain later can be a problem - ...


2

Should I enforce this coding style? Probably not. My rule is this: header file inclusion cannot be order dependent. You can verify this quite easily with the simple rule that the first file included by x.c is x.h.


1

doesn't #Pragma once achieve this? You can include something as many times as you want, either directly or via chained includes, and as long as there is a #Pragma once next to each of them, the header is only included once. As to enforcing it, well maybe you could create a build system that just includes each header by itself with some dummy main function, ...


1

I don't think such a tool exists, but I would be happy if some other answer disproves me. The problem with writing such a tool is that it very easily reports a false result, so I estimate the net advantage of such a tool to be close to zero. The only way such a tool could work is if it could reset its symbol table to just the contents of the header file it ...



Only top voted, non community-wiki answers of a minimum length are eligible