Re: lynx-dev coding style, ifdefs

[Klaus Weide]

On Sat, 16 Oct 1999, Vlad Harchev wrote:
> On Sat, 16 Oct 1999, Klaus Weide wrote:
> >   #ifndef NO_BAR
> >           if (bar_flag)
> >   #endif
> >           {
> >               foo(1);
> >               foo(2);
> >           }
[superfluous semicolon excised]

>  Nice thing! I forgot about this. But from performance reasons, your variant 
> is slightly worse (since compilers optimize in basic blocks, if NO_BAR is 
> defined, extra basic block will be created, that will increase code size,
> execution time). Of course, gcc is smart to optimize accross basic blocks, but
> anyway it gives worse code even on gcc I believe.

It seems to me you would prefer to use assembler language...

> > But this kind of thing (if conditions that are conditional on
> > preprocessor stuff) is exactly what makes for unreadable code,
> > as soon as several variables and symbols are involved.  So the
> > best would be simply
> > 
> >           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.

If bar_flag represents a setting that would be generally useful,
OR if code savings that would be realised by omitting the bar_flag
from the code would be minimal, then my opinion is there should be
no conditional code for this.  Just a global variable is fine.

> > Because not everybody is subscribed to lynx-dev.  Because not
> > everybody has your address.  Because not everybody has Internet
> > access.  One should be able to use lynx, and have the source code,
> > in a usable form, without any of those things.
> 
>   Everybody can subscribe and ask lynx-dev (and I'll answer). As for
> inet-access - I can't imagine such people. 

Yup.  How can anybody be so backward.

> As for the last sentence - this is an unreachable target. 

You find it an unreachable target that someone should be able to make use
of the lynx code without online access (and specifically online access to
you)?  That is mind-boggling.

> I'm not so altruistic to spent a lot of time 
> on cleanup and documentation.

That's why I am *not* asking you to clean up or document my or anybody
else's code.

> >[...] 
> > But you could have started with a copy of SGML.c and made changes to that
> > copy.  No writing-from-scratch of existing stuff would have been required.
> > (And, to turn your argument around: you could have asked us.)
> 
>  But making modifications inplace makes them automatically up-todate to all
> code changes (for example you added XML support :)

So it's strictly for your convenience.

Note: I have *not* added XML support.  That is completely wrong, let's not
give false impressions.  Any clain that lynx can parse XML in a meaningful
way would be wrong.  (Unless it's an XHTML document that happens to also
be valid as an HTML document.)

The only XML-ish thing in my patch is that <foo/> is treated as an empty
element, a construct which happens to also be used in XML.  It already
won't work that way when there's anything between "foo" and the "/"
(including a space, I think).

> >[...]
> > > So, programmers' efforts (regrading studying SGML.c) are less signtificant
> > > than the features/flexibility users get with syntax highlighter IMO.
> > 
> > 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.

So all the time Foteos Macrides spent adding comments and explanations
was wasted time, and if he had not done so, Lynx would be in a better shape
now (and would have all the features you need)?  Yeah right.

Those comments are a lot more worth to lynx as a whole than *any* specific
feature, IMO.

[...]
>   But I don't stress on the usability of this. I can remove all such "markup"
> if you and other lynx-devers prefer (and will never use it in the patches).

So you don't object if someone else removes it?
(Not that I'm planning to do that in general...)


   Klaus