Thread: Whitespaces before macro bracket

  1. #1
    Registered User
    Join Date
    Dec 2005
    Posts
    32

    Whitespaces before macro bracket

    I believe I read somewhere that you should always align the preprocessor # in the first column, but now I'm having trouble verifying my sources. I googled, but didn't find any real good info. Is there a rule or recommendation on placing whitespaces before the bracket? Or immediately after, for that matter. I've seen different constructs:

    Code:
    #ifdef FOO
     #include "foo.h"
    #endif
    Code:
    #ifdef FOO
    # include "foo.h"
    #endif
    The reason I'm asking is that I've started using the following approach when it comes to debugging:

    Code:
    #ifdef DEBUG
    printf("Test print: foo");
    #endif
    Deep inside functions, this would look a bit bizarre if I have to keep the macros in the first column. If that's the recommendation though, I will of course adapt. There must be a succinct guideline for this somewhere - please point me in the right direction!

    Thanks!
    -tretton

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Leading indentation before a # is a style issue.
    Like all style issues, there are some good arguments for both sides.

  3. #3
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466

    You could do this..

    Instead of using #define,
    Code:
    const bool DEBUG = true;
    Then you could use an if statement nested deep as you want
    without worrying about preprocessor formatting.

    EDIT: Sorry, I'm not sure const is even part of C. If it's not my apologies, I guess I really am a C++ guy.

    Maybe try this:
    Code:
    #define DEBUG 1
    ...and do the if test as I said above. Then to turn off debugging change it to 0.
    Last edited by MacNilly; 02-21-2006 at 04:57 AM.

  4. #4
    Yes, my avatar is stolen anonytmouse's Avatar
    Join Date
    Dec 2002
    Posts
    2,544
    I believe I read somewhere that you should always align the preprocessor # in the first column
    I was under this impression also, but a quick check of the C89 draft says this:
    A preprocessing directive consists of a sequence of preprocessing tokens that begins with a # preprocessing token that is either the first character in the source file (optionally after white space containing no new-line characters) or that follows white space containing at least one new-line character, and is ended by the next new-line character.
    It appears that it was a requirement of some pre-ansi preprocessors. GCC can still be instructed to use this requirement by using the -traditional flag.

    Many programmers put the indentation between the # and the command:
    Code:
    #if defined(DEBUG)
    #    include <debug.h>
    #    if defined(SUPER_DEBUG)
    #        include <super_debug.h>
    #    endif
    #endif
    Even if it is not required, this can be good style as it enables the preprocessor commands to be easily spotted by scanning down the first column.

  5. #5
    ex-DECcie
    Join Date
    Dec 2005
    Posts
    125
    I still put my #ifdef DBG stuff starting in column 1. As Salem says it is a style issue, but for me, when I have a ton of code, if I want to comment out some debug statements, they are right there in column 1.

    Your mileage may vary, of course.

  6. #6
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    Quote Originally Posted by tretton
    The reason I'm asking is that I've started using the following approach when it comes to debugging:

    Code:
    #ifdef DEBUG
    printf("Test print: foo");
    #endif
    Consider doing something like this (if your print function is always simple like in your example).
    Code:
    #ifndef NDEBUG
    #define TRACE(x) puts(x)
    #else
    #define TRACE(x)
    #endif
    Populate your function(s).
    Code:
    int foo(int i)
    {
       TRACE("foo");
       return i;
    }
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem building Quake source
    By Silvercord in forum Game Programming
    Replies: 16
    Last Post: 07-11-2010, 09:13 AM
  2. whitespaces
    By happyclown in forum C Programming
    Replies: 2
    Last Post: 01-06-2009, 10:33 PM
  3. Errors including <windows.h>
    By jw232 in forum Windows Programming
    Replies: 4
    Last Post: 07-29-2008, 01:29 PM
  4. Quantum Random Bit Generator
    By shawnt in forum C++ Programming
    Replies: 62
    Last Post: 06-18-2008, 10:17 AM
  5. Sorting through delimiting characters
    By Aluvas in forum C++ Programming
    Replies: 4
    Last Post: 11-19-2002, 01:42 PM