Re: lynx-dev Dead code tactics: call for comments

[Philip Webb]

990312 John Bley invited comments: 
> I've enumerated several dozen functions which I believe are dead code.  
> In addition, there are several thousand lines sitting
> between dead #if constructions (a wide variety of them).
> There are code-level features (such as SHORT_NAMES)
> that haven't been used in a long time and wouldn't work anyway
> with a current source tree since newer code doesn't adhere to them.
> Here are five tactics for dealing with the dead code in lynx
> (which I'd estimate at  about 3 % ).
> 
> 1) "Complete removal."  Remove dead files such as HTAAServ.c,
> cut the lines between #if 0 and company, etc.
> This means some elements of "history" might get lost,
> since lynx doesn't have a publicly-readable cvs server.
>    PRO: smaller code base, smaller distribution, smaller binary, etc.
>    CON: "History loss" unless a source control system is implemented

people have long been grumbling at the size of Lynx source,
both as a big stumbling-block for newcomers
& as a pain to maintain, esp if long-time regulars fall by the way;
already, too few people feel at ease working on the stuff.
so (1) seems the obvious choice,
esp if combined with a permanent archive of what's been removed.

> 2) "Partial removal/partial commenting."  On a case-by-case basis,
> decide whether the code is interesting enough to save and comment out,
> or if it can be tossed without any loss.
>    PRO: Loss of only meaningless things, smaller binary
>    CON: Many man-hours and bickering over what to keep/toss

too much fuss, not enough volunteer time.

> 3) "Comment everything."  Remove makefile targets for unused files
> but leave them in the distribution, comment out all the dead code,
> leave stuff that is currently #if 0-ed in place.
>    PRO: No history loss, smaller binary, only a little time wasted
>    CON: Distribution actually grows a little bit

still time-consuming & too many comments can make for more confusion.

> as a relative newcomer to the source tree, I've been diverted many times
> by code only to find it was sitting in a #if 0-type construct.
> A smaller distribution means new coders have an easier time learning
> how to program for lynx and don't waste time patching dead code.

i hope LE & KD will comment on this issue: both may be absent right now.

> Leading me to what I think is a compromise solution 
> 4) "Move it or lose it".  Lacking a proper source control system,
> move dead code chunks/files to a "deadsrc" directory or something similar, 
> possibly leaving comments in place pointing out
> "X used to be here but was moved to deadsrc/ on <date>".
>    PRO: smaller binary, no history loss, not much time wasted,
>         new coders adapt easily
>    CON: Distribution grows a little

this is close to my picture of (1):
the dead code needn't be distributed, merely centrally preserved somewhere.
but better than commenting the on-going source,
preserve the whole present state of things for people to explore if they wish,
while allowing the developing code to take off on its own.
a good point to freeze the historic picture would be 2-8-2rel.1 ,
which would be carefully preserved IN TOTO somewhere safe & public,
while 2-8-3dev.1 would result from (your) patches deleting dead wood,
which would also be carefully preserved for people to see what was changed.
once the deletion patches are made, it's really a simple process.

> Of course, there's also the easiest solution of all,
> 5) "Nop."  Do nothing.  Who cares about a few K of binary or tarball?
>    PRO: Easy.
>    CON: The binary and tar file keep growing.

the big objection is the one above:
it's already too big for volunteer programmers to master.

> I think the only proper, long-term strategy is to adopt
> a source control mechanism so that the project history can be examined,
> and then to use (1).  But I recognize changing the development process
> affects every developer & makes the maintainer's task harder short term.
 
we don't need a formal project-control mechanism.
the number of people who have contributed to Lynx source since 980101
is probably around  1 dozen  & REGULAR contributors less than that:
part of the reason is the intimidating size for anyone new to it.
of course, you are  1  of the dozen (smile).

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto