Re: #if 0

Discussion in 'C++' started by Juha Nieminen, Jan 20, 2009.

  1. Jung, William wrote:
    > #if 0
    > m_Picture.Create("images/" + url);
    > #endif


    This is a technique used to easily comment out portions of the code.
    It's handy because if you want to re-include the code, you just have to
    change the "0" to "1", rather than having to touch both the beginning
    and the end of the comment block.
     
    Juha Nieminen, Jan 20, 2009
    #1
    1. Advertising

  2. Juha Nieminen

    James Kanze Guest

    On Jan 21, 12:49 am, Juha Nieminen <> wrote:
    > Jung, William wrote:
    > > #if 0
    > > m_Picture.Create("images/" + url);
    > > #endif


    > This is a technique used to easily comment out portions of the
    > code. It's handy because if you want to re-include the code,
    > you just have to change the "0" to "1", rather than having to
    > touch both the beginning and the end of the comment block.


    It was common practice back in the days of C---C style comments
    don't nest, so bracketing the block with /*...*/ didn't work if
    it contained a comment.

    A variant used a reserved identifier, e.g.:

    #ifdef COMMENTED_OUT
    ...
    #endif

    This had the advantage of being explicit. And the disadvantage
    that there was always some idiot who'd define COMMENTED_OUT to
    reactivate his commented out block, reactivating everyone elses
    at the same time.

    This technique has pretty much died with the introduction of C
    style comments and syntax coloring in editors. It's trivial to
    do something like ``'a,'bs:^:// :'' in the editor, to comment
    out a block, and this results in the editor syntax coloring the
    block as comments (and even without syntax coloring, you see
    that the block is commented out, even if the top and bottom of
    the block are not visible). It does have the disadvantage that
    it doesn't directly support additional information, along the
    lines of:

    #ifdef COMMENTED_OUT_TO_BE_DELETED_ONCE_THE_ABOVE_WORKS

    (But I've never seen such additional information effectively
    used. And I've seen code with such block, in which the "above"
    had been fully tested and working for the last five or six
    versions.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jan 21, 2009
    #2
    1. Advertising

  3. Juha Nieminen

    Jorgen Grahn Guest

    On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze <> wrote:
    > On Jan 21, 12:49 am, Juha Nieminen <> wrote:
    >> Jung, William wrote:
    >> > #if 0
    >> > m_Picture.Create("images/" + url);
    >> > #endif

    >
    >> This is a technique used to easily comment out portions of the
    >> code. It's handy because if you want to re-include the code,
    >> you just have to change the "0" to "1", rather than having to
    >> touch both the beginning and the end of the comment block.

    >
    > It was common practice back in the days of C---C style comments
    > don't nest, so bracketing the block with /*...*/ didn't work if
    > it contained a comment.
    >
    > A variant used a reserved identifier, e.g.:
    >
    > #ifdef COMMENTED_OUT
    > ...
    > #endif
    >
    > This had the advantage of being explicit. And the disadvantage
    > that there was always some idiot who'd define COMMENTED_OUT to
    > reactivate his commented out block, reactivating everyone elses
    > at the same time.
    >
    > This technique has pretty much died with the introduction of C
    > style comments and syntax coloring in editors.


    I still use it, and I almost never comment out code with /* or //.
    (Emacs does coloring of preprocessor blocks too, by the way.)

    What I hope is killing both techniques is version control. There is
    usually need to keep code "just in case" more than temporarily, when
    it can be retrieved from the file's history (hopefully with some
    checkin comment explaining why it was removed).

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
     
    Jorgen Grahn, Jan 21, 2009
    #3
  4. Juha Nieminen

    Ian Collins Guest

    Jorgen Grahn wrote:
    > On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze <> wrote:
    >> On Jan 21, 12:49 am, Juha Nieminen <> wrote:
    >>> Jung, William wrote:
    >>>> #if 0
    >>>> m_Picture.Create("images/" + url);
    >>>> #endif
    >>> This is a technique used to easily comment out portions of the
    >>> code. It's handy because if you want to re-include the code,
    >>> you just have to change the "0" to "1", rather than having to
    >>> touch both the beginning and the end of the comment block.

    >> It was common practice back in the days of C---C style comments
    >> don't nest, so bracketing the block with /*...*/ didn't work if
    >> it contained a comment.
    >>
    >> A variant used a reserved identifier, e.g.:
    >>
    >> #ifdef COMMENTED_OUT
    >> ...
    >> #endif
    >>
    >> This had the advantage of being explicit. And the disadvantage
    >> that there was always some idiot who'd define COMMENTED_OUT to
    >> reactivate his commented out block, reactivating everyone elses
    >> at the same time.
    >>
    >> This technique has pretty much died with the introduction of C
    >> style comments and syntax coloring in editors.

    >
    > I still use it, and I almost never comment out code with /* or //.
    > (Emacs does coloring of preprocessor blocks too, by the way.)
    >
    > What I hope is killing both techniques is version control. There is
    > usually need to keep code "just in case" more than temporarily, when
    > it can be retrieved from the file's history (hopefully with some
    > checkin comment explaining why it was removed).
    >

    Yes, version control is the way to go. My last team had a strict "no
    commented out code" rule and the code base was much cleaner for it.

    --
    Ian Collins
     
    Ian Collins, Jan 21, 2009
    #4
  5. Juha Nieminen

    Bertrand Guest

    Jorgen Grahn wrote:
    > I still use it, and I almost never comment out code with /* or //.
    > (Emacs does coloring of preprocessor blocks too, by the way.)

    and vim too :p

    --
    Bertrand
     
    Bertrand, Jan 22, 2009
    #5
  6. Juha Nieminen

    James Kanze Guest

    On Jan 21, 10:53 pm, Ian Collins <> wrote:
    > Jorgen Grahn wrote:
    > > On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze <> wrote:
    > >> On Jan 21, 12:49 am, Juha Nieminen <> wrote:
    > >>> Jung, William wrote:
    > >>>> #if 0
    > >>>> m_Picture.Create("images/" + url);
    > >>>> #endif
    > >>> This is a technique used to easily comment out portions of the
    > >>> code. It's handy because if you want to re-include the code,
    > >>> you just have to change the "0" to "1", rather than having to
    > >>> touch both the beginning and the end of the comment block.
    > >> It was common practice back in the days of C---C style comments
    > >> don't nest, so bracketing the block with /*...*/ didn't work if
    > >> it contained a comment.


    > >> A variant used a reserved identifier, e.g.:


    > >> #ifdef COMMENTED_OUT
    > >> ...
    > >> #endif


    > >> This had the advantage of being explicit. And the disadvantage
    > >> that there was always some idiot who'd define COMMENTED_OUT to
    > >> reactivate his commented out block, reactivating everyone elses
    > >> at the same time.


    > >> This technique has pretty much died with the introduction of C
    > >> style comments and syntax coloring in editors.


    > > I still use it, and I almost never comment out code with /* or //.
    > > (Emacs does coloring of preprocessor blocks too, by the way.)


    > > What I hope is killing both techniques is version control. There is
    > > usually need to keep code "just in case" more than temporarily, when
    > > it can be retrieved from the file's history (hopefully with some
    > > checkin comment explaining why it was removed).


    > Yes, version control is the way to go. My last team had a strict "no
    > commented out code" rule and the code base was much cleaner for it.


    I agree for checked-in code. I'll comment out while I've got
    the code checked out, if I want to experiment something. (The
    usual goal is to have the original code handy and viewable, so I
    can compare it with the new code.)

    Of course, as long as it isn't checked in, it really doesn't
    matter what you use to comment out.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jan 22, 2009
    #6
  7. Juha Nieminen

    James Kanze Guest

    On Jan 21, 4:21 pm, Jorgen Grahn <> wrote:
    > On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze
    > <> wrote:
    > > On Jan 21, 12:49 am, Juha Nieminen <> wrote:
    > >> Jung, William wrote:
    > >> > #if 0
    > >> > m_Picture.Create("images/" + url);
    > >> > #endif


    > >> This is a technique used to easily comment out portions of
    > >> the code. It's handy because if you want to re-include the
    > >> code, you just have to change the "0" to "1", rather than
    > >> having to touch both the beginning and the end of the
    > >> comment block.


    > > It was common practice back in the days of C---C style
    > > comments don't nest, so bracketing the block with /*...*/
    > > didn't work if it contained a comment.


    > > A variant used a reserved identifier, e.g.:


    > > #ifdef COMMENTED_OUT
    > > ...
    > > #endif


    > > This had the advantage of being explicit. And the
    > > disadvantage that there was always some idiot who'd define
    > > COMMENTED_OUT to reactivate his commented out block,
    > > reactivating everyone elses at the same time.


    > > This technique has pretty much died with the introduction of
    > > C style comments and syntax coloring in editors.


    > I still use it, and I almost never comment out code with /* or
    > //. (Emacs does coloring of preprocessor blocks too, by the
    > way.)


    How? How can it know whether COMMENTED_OUT is defined or not?

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Jan 22, 2009
    #7
  8. Juha Nieminen

    zr Guest

    On Jan 22, 2:12 am, Bertrand <> wrote:
    > Jorgen Grahn wrote:
    > > I still use it, and I almost never comment out code with /* or //.
    > > (Emacs does coloring of preprocessor blocks too, by the way.)

    >
    > and vim too :p
    >
    > --
    > Bertrand


    Add Visual Studio to the list.
     
    zr, Jan 22, 2009
    #8
  9. Juha Nieminen

    Jorgen Grahn Guest

    On Thu, 22 Jan 2009 01:46:44 -0800 (PST), James Kanze <> wrote:
    > On Jan 21, 4:21 pm, Jorgen Grahn <> wrote:
    >> On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze
    >> <> wrote:

    ....

    >> > A variant used a reserved identifier, e.g.:

    >
    >> > #ifdef COMMENTED_OUT
    >> > ...
    >> > #endif

    >
    >> > This had the advantage of being explicit. And the
    >> > disadvantage that there was always some idiot who'd define
    >> > COMMENTED_OUT to reactivate his commented out block,
    >> > reactivating everyone elses at the same time.

    >
    >> > This technique has pretty much died with the introduction of
    >> > C style comments and syntax coloring in editors.

    >
    >> I still use it, and I almost never comment out code with /* or
    >> //. (Emacs does coloring of preprocessor blocks too, by the
    >> way.)

    >
    > How? How can it know whether COMMENTED_OUT is defined or not?


    As far as I can see, you have to tell it at runtime. "Text which
    depends on COMMENTED_OUT being set should be [black/green/
    gray/.../hidden]" and similarly for !COMMENTED_OUT.

    (But I guess it *could* have colorized automatically: picking the
    largest block of ifdefed text and assigned the "best" color to it, and
    so on in priority order.)

    I don't use it much; Thankfully, I haven't had to work much with
    ifdef-poisoned code. (Knock on wood.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
     
    Jorgen Grahn, Jan 23, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page