Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: #if 0

Reply
Thread Tools

Re: #if 0

 
 
Juha Nieminen
Guest
Posts: n/a
 
      01-20-2009
Jung, William wrote:
> #if 0
> m_Picture[i].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.
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      01-21-2009
On Jan 21, 12:49 am, Juha Nieminen <(E-Mail Removed)> wrote:
> Jung, William wrote:
> > #if 0
> > m_Picture[i].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:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-21-2009
On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze <(E-Mail Removed)> wrote:
> On Jan 21, 12:49 am, Juha Nieminen <(E-Mail Removed)> wrote:
>> Jung, William wrote:
>> > #if 0
>> > m_Picture[i].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!
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-21-2009
Jorgen Grahn wrote:
> On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze <(E-Mail Removed)> wrote:
>> On Jan 21, 12:49 am, Juha Nieminen <(E-Mail Removed)> wrote:
>>> Jung, William wrote:
>>>> #if 0
>>>> m_Picture[i].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
 
Reply With Quote
 
Bertrand
Guest
Posts: n/a
 
      01-22-2009
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

--
Bertrand
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-22-2009
On Jan 21, 10:53 pm, Ian Collins <(E-Mail Removed)> wrote:
> Jorgen Grahn wrote:
> > On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze <(E-Mail Removed)> wrote:
> >> On Jan 21, 12:49 am, Juha Nieminen <(E-Mail Removed)> wrote:
> >>> Jung, William wrote:
> >>>> #if 0
> >>>> m_Picture[i].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:(E-Mail Removed)
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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-22-2009
On Jan 21, 4:21 pm, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze
> <(E-Mail Removed)> wrote:
> > On Jan 21, 12:49 am, Juha Nieminen <(E-Mail Removed)> wrote:
> >> Jung, William wrote:
> >> > #if 0
> >> > m_Picture[i].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:(E-Mail Removed)
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
 
Reply With Quote
 
zr
Guest
Posts: n/a
 
      01-22-2009
On Jan 22, 2:12*am, Bertrand <(E-Mail Removed)> 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
>
> --
> Bertrand


Add Visual Studio to the list.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-23-2009
On Thu, 22 Jan 2009 01:46:44 -0800 (PST), James Kanze <(E-Mail Removed)> wrote:
> On Jan 21, 4:21 pm, Jorgen Grahn <(E-Mail Removed)> wrote:
>> On Wed, 21 Jan 2009 00:49:59 -0800 (PST), James Kanze
>> <(E-Mail Removed)> 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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments