It is always said that the include directives should be placed at the beginning of a script. The main reason is to make the functions available throughout the script. Regardless of this fact, is it bad to place an include directive within the main function where it is needed?

For example,

#include <stdio.h>
int main() {
#include <mysql.h>

Instead of

#include <mysql.h>
#include <stdio.h>
int main() {

I was unable to find any different in performance or compiled file size, but it is difficult to judge about this fact based on simple scripts. I wonder if it has any effect or drawback, or any reason to avoid this non-standard approach.

  • 2
    Oh, the joys of debugging when someone puts a function in the .h with that include.
    – user40980
    Aug 21, 2013 at 3:49
  • You said it in your question: Its non standard. Doing things differently from normal cause maintenance problems when things go wrong (because now we have to sit a figure out why you did it). Aug 21, 2013 at 7:40

5 Answers 5


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 contains function and variable declarations, putting them inside the body of main() limits their scope.

If the header file only contains preprocessor macros it might work, but you'll annoy all other C programmers by gratuitously moving the include somewhere unexpected. Coding standards are particularly important in C because C has so few safeguards to keep you from screwing up.

  • 1
    +1. Even if this works for the current version of a third party library, it may break in the next, since the library provider will typically assume that you use the includes in the standard way.
    – Doc Brown
    Aug 21, 2013 at 6:19
  • Unfortunately it is legal in C to call undefined functions, and even more unfortunately its common in legacy code bases. Scope limitation of functions is limited to compiler level and warnings......
    – mattnz
    Aug 21, 2013 at 19:55

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?

I know where I'm going.  Really, I do.

  • 1
    Although funny, isn't it getting too derogatory for this site? :)
    – mattnz
    Aug 21, 2013 at 3:37
  • 1
    @mattnz: The picture is meant to be illustrative. Isn't programming difficult enough already? Aug 21, 2013 at 3:40
  • Thanks for the note, but I am curious about any serious drawback in compiling rather than preference in coding.
    – Googlebot
    Aug 21, 2013 at 3:46
  • 10
    Being unnecessarily difficult to maintain is a serious drawback. Aug 21, 2013 at 4:18

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 block.
  • Declarations of types, variables and functions. Their scope will be the block where the #include directive is located. That's usually fine. However, it works only once. Almost all include files contain header guards, so that if the file is included more than once (which often happens due to headers requiring other headers) its content is only processed once. So if you #include the same header in multiple functions, the declarations will only be available the first time.
  • Definitions of functions (or variables, but that's extremely rare in headers). Headers sometime contain small static functions which the compiler can inline. These will cause the compilation to fail if the #include directive is inside the function, because (barring some compiler extensions) you can't define a function inside another function.

So it's not just a matter of style: #include inside a function often plain doesn't work.

You can put an #include directive anywhere at file scope (i.e. outside a function) with no major technical ill effects. The entities that it defines would only be available below the #include line. That's mostly a matter of style, but it's unusual and pointless so it will confuse maintainers. It can also lead to confusing errors if you define a variable or function of the same name as something declared in a header, because then any mismatch will be reported in the header (or in a header included in a header included … included in that header), possibly using weird implementation-specific syntax, rather than in your code.

So yes, it's bad. Group all your #include directives near the top of the file, with nothing other than comments and the occasional #pragma or #define if instructed by your implementation's documentation.


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;

macro variables have a "file" scope whereas any variables defined within will have function scope if you include the "#INCLUDE" within a function.


    #include <stdio.h>
    int main() {
        #include <mysql.h>
        call doSql();
     int doSql () {
        #include <mysql.h>

Will not compile as the macro variable MYSQL is already defined and the second INCLUDE will not define anything.


long things short ... just avoid it as much as you can , do it only when it's Absolutely necessary (I can't think of a case where it is but who knows), in order to have a clean maintainable code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.