Re: lynx-dev coding style, ifdefs

[Vlad Harchev]

On Sat, 16 Oct 1999, Klaus Weide wrote:

> On Fri, 15 Oct 1999, Vlad Harchev wrote:
> >  I tried to say that I don't do boolean expressions optimization in
> > preprocessor's conditionals yet:)
> 
> I still don't understand - hope it isn't important.
> You are a programmer (or hacker, or whatever - a human at any rate),
> why should you do a programs job?

  Yes, it's not important. Some people prefer instead of (!A || !B) to write
!(A && B). I don't do this - that's what I meant.
 
>[...] 
> The fact that indentation is "right" for one set of preprocessor
> macros and wrong for another should show you that you shouldn't do it
> this way at all.
> 
> Make it
>  
>   #ifndef NO_BAR
>           if (bar_flag) {
>               foo(1);
>               foo(2);
>           };
>   #else
>           foo(1);
>           foo(2);
>   #endif
> 
> or better
> 
>   #ifdef NO_BAR
>           foo(1);
>           foo(2);
>   #else
>           if (bar_flag) {
>               foo(1);
>               foo(2);
>           };
>   #endif
> 
> or even better
> 
>   #ifdef BAR
>           if (bar_flag) {
>               foo(1);
>               foo(2);
>           };
>   #else
>           foo(1);
>           foo(2);
>   #endif
> 
> for readability, as long as foo(1), foo(2) is small.
> Or, if you must make the condition itself alone dependent
> on preprocessor conditions, write
> 
>   #ifndef NO_BAR
>           if (bar_flag)
>   #endif
>           {
>               foo(1);
>               foo(2);
>           };

 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.
 
> 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.
 
> 
> > > > And anybody can ask me what something means.
> > > 
> > > That's a nice offer.  How long will it be valid?
> > 
> >   You fear that I will leave lynx development some day (I don't say you are 
> > wrong)... Anyway, I will provide support (consultations).
> > 
> > > But it is irrelevent.  Nobody *should* have to ask you.
> > 
> >   Proper documentation of the code takes a lot of time. 
> 
> Writing some comments certainly takes less time than discussions on
> lynx-dev and "providing consultations".
> 
> > > And not everybody *can* ask you.
> > 
> >   Why?
> 
> 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. 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.

>[...] 
> 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, 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. As for free
software - I don't agree with you.

>[...] 
> If I read you right, you have already agreed that parts of your recent
> code contributions need cleanup.  I hope you will find the time to do
> that, even if you prefer to spend your time otherwise.

 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.

> 
> > > So your output (as it has ended up in the dev. code) is not a final
> > > product, it is just an intermediate stage?
> > 
> >  All open-source products are subject to extending and enchancing. IMO
> > denoting places that responsible for particular feature will help future
> > developers to understand and enchance lynx code. 
> 
> That's what C has  /* COMMENTS */  for!

 May be...

> > As you saw, I leave both
> > branches of conditionals (this is more than just providing marks) - yes, 
> > this
> > can be considered redundant (but this more consistent way of utilizing cpp
> > conditionals - isn't it?).
> 
> I shouldn't have to learn some special Vlad-preprocessing mode (by guessing -
> it isn't spelled out anywhere) before I can make sense of it.

  I wonder - are you serious to consider the way of marking all changes the
special preprocessing mode?
  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.
  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).
   
> > > > As I remember, I posted cpp condition simplifier (as
> > > > awk script, that remove 'conditionals with constant value' - just tell 
> > > > it that
> > > > NO_DUMP_WITH_BACKSPACES is always 0 and pass a code through it - thou' 
> > > > it
> > > > can't handle expressions like x || y).
> > > 
> > > Why do you bring that up?  I am talking about the code that is distributed
> > > in the dev.N .tar's and .zip's, not about anything one could 
> > > hypothetically
> > > make out of that with this or that tool.
> > 
> >  I meant that if these marks thierself will be considered redundant, they 
> > can
> > be removed with the use of tools easily (rather than by hand).
> 
> So remove those that are in the way - whether you do it by hand or with
> some fancy 'cpp condition simplifier' I don't care.

  If other lynx-devers agree, I will do it when I'll have time (this will
happen after XMas).

>[...]
> > > > And I'm sorry
> > > > for OPT, OPT1 - these was an attempt for optimizations. I hope I will 
> > > > clear
> > > > them one day.
> 
> So do I. :)

  I'll do it when I have time - read above :)

>[...] 

 Best regards,
  -Vlad