[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev coding style, ifdefs

From: Mike Castle
Subject: Re: lynx-dev coding style, ifdefs
Date: Sat, 16 Oct 1999 15:12:07 -0500

On Sat, Oct 16, 1999 at 12:40:21PM +0500, Vlad Harchev wrote:
> >           if (bar_flag) {
> >               foo(1);
> >               foo(2);
> >           };
>       This will require the bar_flag to exist either as global variable or
> macro. And this will create basic block too.

The loss of optimization is NOT worth the extra cost of maintenance.  Make
the code easier to maintain; not run faster.  Until you see, and prove, the
need to squeeze a little extra performance out of it, it is MUCH better to
make to code easier to maintain.

>   Everybody can subscribe and ask lynx-dev (and I'll answer). As for
> inet-access - I can't imagine such people. As for the last sentence - this is
> an unreachable target. I'm not so altruistic to spent a lot of time 
> on cleanup and documentation.

I'd rather see you spend time working on cleanup and documentation (which
can be useful to many) than something like justification and hyphenation 
(which is pretty much useless to most people).

Sure, it's your time.  It's also your arrogance.

Personally, I'm almost tempted to ask for the contributors to consider that
all patches, especially major enhancements/additions, be accompanied by
appropriate documentation (be it comments in the code, user documentation,
etc) before they are accepted.  In the past, I don't think this was
necessary, because the contributors did make the effort to make the program
maintainable.  But you seem to go out of your way to do just the opposite.
It seems that you think you are too good to do something menial like
commenting code.

> > Take this a step further, and you are basically saying that all that's
> > important is that users get features.  Don't bother about the coders.
> > Well if everyone before you had thought that way, you wouldn't have any
> > sort of more-or-less readable code to start playing with.  Maybe you
> > wouldn't have any free software.
>   If everyone before me had thought that way, I probably wouldn't have started
> lynx hacking since the features I need were already there. As for free
> software - I don't agree with you.

If everyone thought as you, Lynx would be even more of a mess than it
already is!

>  Yes I agree parts of my code contributions need cleanup. But agreement
> doesn't convince me to do this immediately or in the next 2 monthes. I'm busy
> at this moment.

Busy doing things that are less import to the Lynx project as a whole than
what you are doing now.

> > That's what C has  /* COMMENTS */  for!
>  May be...

Not ``maybe''; by definition, that's what they are for.

>   Here it is spelled out then:
> Pretend that each added functionality can be switched on or off at
> compile-time, invent the macro name starting with NO_ - that macro should be
> defined to disable that functionality at compile-time. Then write the code in
> the way that will allow to restore the logic before the functionality was 
> added by defining the NO_ macro mentioned.

Fortunately, this can often be accomplished by a single, simple run time
configuration element.  We don't have to clutter up the entire code base
with a bunch of ifdefs like that; we can, instead, just leave them there.

For MAJOR parts of code, the make a significant contribution to code size, 
perhaps.  But for minor enhancements, it just makes maintaining the code a

Also, I suggest you go to
and read much of the reference material there, especially the paper
written by Spencer and Collyer on using #ifdefs.

       Mike Castle       Life is like a clock:  You can work constantly
  address@hidden  and be right all the time, or not work at all and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]